ISP 장비의 종말? eBPF와 XDP로 구현한 분산형 BNG 아키텍처 분석

네트워크 엔지니어링이나 인프라 아키텍처를 다루다 보면, 항상 마주치는 딜레마가 있습니다. “비싸고 안정적인 벤더 장비(Appliance)를 살 것인가, 아니면 범용 하드웨어에 소프트웨어를 얹어 직접 구축할 것인가?”

최근 Hacker News에서 꽤 흥미로운 포스트 하나가 화제가 되었습니다. Mark Gascoyne이라는 엔지니어가 쓴 Killing the ISP Appliance: An eBPF/XDP Approach to Distributed BNG 라는 글입니다. 수억 원을 호가하는 통신사 장비(BNG)를 리눅스 박스와 eBPF 코드로 대체하겠다는, 다소 도발적이면서도 기술적으로 매우 설득력 있는 시도입니다.

오늘은 이 아키텍처를 깊게 뜯어보고, 현업 엔지니어 관점에서 이게 과연 ‘장난감’인지 ‘미래’인지 분석해보려 합니다.

1. 문제는 ‘중앙집중형’ 병목이다

전통적인 ISP(인터넷 서비스 제공자)의 망 구조는 매우 수직적입니다. 가입자(Customer)의 트래픽은 OLT(광선로 종단 장치)를 거쳐 중앙의 거대한 BNG(Broadband Network Gateway) 장비로 모입니다. 이 BNG가 DHCP, 인증, NAT, QoS 등 모든 것을 처리하죠.

  • Single Point of Failure: BNG가 죽으면 해당 지역 인터넷이 전멸합니다.
  • Vendor Lock-in: 시스코, 주니퍼, 노키아 같은 벤더의 장비는 수억 원대입니다. 유지보수 비용은 덤이죠.

이 글의 저자는 “왜 굳이 중앙으로 트래픽을 끌고 와서 처리해? 그냥 엣지(Edge)인 OLT에서 처리하면 되잖아?” 라는 질문을 던집니다. 하이퍼스케일러들이 엣지 컴퓨팅을 하는 방식과 똑같습니다.

2. VPP 대신 eBPF를 선택한 이유 (이게 핵심입니다)

보통 고성능 패킷 처리를 논할 때 업계 표준은 VPP(Vector Packet Processing) 와 DPDK 입니다. 100Gbps 이상의 코어 네트워크에서는 당연한 선택이죠. 하지만 저자는 엣지 단(OLT 당 10~40Gbps)에서는 eBPF/XDP 가 더 낫다고 판단했습니다. 이 결정에 저는 100% 동의합니다.

그 이유는 ‘운영 복잡도’ 때문입니다.

  • VPP/DPDK: 별도 NIC 드라이버, Hugepages 설정, 전용 CPU 코어 할당 등 세팅이 복잡합니다. 디버깅하려면 전용 툴을 써야 하죠.
  • eBPF/XDP: 그냥 리눅스 커널입니다. tcpdump, bpftool 같은 표준 리눅스 도구로 디버깅이 가능합니다. systemd로 관리하면 끝입니다.

엔지니어링은 항상 Trade-off 입니다. 엣지 장비 수백 대를 관리해야 한다면, 성능을 조금 희생하더라도 운영이 쉬운 기술 스택을 고르는 게 시니어의 판단이죠.

3. 아키텍처: Fast Path와 Slow Path의 분리

이 프로젝트의 백미는 DHCP 처리 방식입니다. 저자는 트래픽을 두 가지 경로로 나눴습니다.

The Fast Path (Kernel/XDP)

대부분의 DHCP 트래픽은 단순한 ‘갱신(Renewal)’ 요청입니다. 이미 아는 가입자죠. 이걸 굳이 유저스페이스(Userspace)까지 올릴 필요가 있을까요?

  1. 패킷이 들어오면 XDP 프로그램이 파싱합니다.
  2. eBPF Map(캐시)에 있는 가입자인지 확인합니다.
  3. Cache Hit: 커널 레벨에서 즉시 DHCP ACK를 만들어 쏘아 보냅니다 (XDP_TX).

결과적으로 10마이크로초(μs) 내에 처리가 끝납니다. 유저스페이스 컨텍스트 스위칭 비용이 ‘0’입니다.

The Slow Path (Userspace/Go)

처음 보는 가입자거나 인증이 필요한 경우에만 XDP_PASS를 통해 Go 언어로 작성된 유저스페이스 애플리케이션으로 패킷을 넘깁니다. 여기서 RADIUS 인증, DB 조회 등을 수행하고 eBPF Map을 업데이트합니다.

// 개념적인 XDP 로직 (bpf/dhcp_fastpath.c)
SEC("xdp")
int xdp_prog(struct xdp_md *ctx) {
    // 1. 패킷 파싱
    // 2. eBPF Map 조회
    if (lookup_subscriber(mac_addr)) {
        // 3. 커널에서 직접 응답 생성 및 전송
        return XDP_TX;
    }
    // 4. 모르면 유저스페이스로 토스
    return XDP_PASS;
}

4. Hacker News의 반응과 현실적인 한계

이 글에 대한 Hacker News의 반응도 매우 날카로웠습니다. 몇 가지 인상 깊은 코멘트를 짚어보겠습니다.

  • “DHCP 갱신이 그렇게 빈번한가?” 한 유저가 지적했듯, OLT당 가입자가 2,000명이고 리스 타임이 5분이라면 초당 갱신 요청은 몇 건 안 됩니다. 굳이 커널에서 처리할 필요가 있었냐는 것이죠. 전형적인 ‘오버 엔지니어링’일 수 있다는 지적입니다. 하지만 랙(Rack) 단위로 집적도가 높아지면 의미가 있을 수 있습니다.

  • “Cisco와 Metaswitch도 시도했다가 망했다” 이 코멘트가 가장 뼈아픕니다. 10년 전 시스코의 cnBNG, 그리고 MS가 인수한 Metaswitch도 비슷한 시도를 했습니다. 기술이 부족해서가 아닙니다. 통신사(Telco)들의 보수적인 문화와, 레거시 장비가 지원하는 수백 가지의 잡다한 기능(RFC XYZ 등)을 100% 맞추지 못하면 도입을 거부당하기 때문입니다.

  • “Whitebox OLT의 성능 문제” 저렴한 $7,400짜리 OLT 장비(Radisys 등)의 CPU와 NPU 간 대역폭이 실제로 트래픽을 전부 처리할 수 있느냐는 의문도 있습니다. 컨트롤 플레인 패킷만 처리하도록 설계된 CPU에 데이터 플레인을 올리는 건 위험할 수 있습니다.

5. 결론: 기술은 준비되었다, 시장이 문제일 뿐

이 프로젝트는 오픈 소스로 공개되어 있습니다(GitHub 링크). 코드를 뜯어보면 Go와 eBPF가 얼마나 우아하게 결합될 수 있는지 보여주는 훌륭한 교보재입니다.

제 개인적인 평가는 이렇습니다:

  1. 기술적 완성도: 매우 높습니다. 특히 IP 할당을 RADIUS 인증 시점에 해시링(Hashring)으로 결정하여 분산 환경의 동기화 문제를 없앤 설계는 천재적입니다.
  2. 상용화 가능성: 대형 통신사(KT, SKB, LGU+ 등)가 이걸 당장 도입할 리는 없습니다. 그들은 책임 소재가 명확한 벤더 장비를 선호하니까요.
  3. 적용처: 하지만 프라이빗 5G망, 소규모 지역 ISP(Altnet), 혹은 사내 대규모 네트워크를 구축해야 하는 테크 기업들에게는 Game Changer 가 될 수 있는 아키텍처입니다.

네트워크 장비가 점점 ‘리눅스 서버’가 되어가고 있습니다. 인프라 엔지니어라면 eBPF는 이제 선택이 아니라 필수 교양 과목이 된 것 같습니다.