grep

Engineering

경계가 만든 길, Load Balancer(DSR)

NHN

2026년 7월 20일

원문에서 보기 ↗

NHN Cloud_meetup banner_DSR_202607_900.png

기존의 프록시 방식 로드 밸런서(LB)는 클라이언트와 서버 사이에서 양쪽 연결을 모두 종단하고 데이터를 중계하는 구조입니다. 요청과 응답이 모두 LB를 경유하기 때문에, 응답 트래픽이 클수록 LB가 병목이 됩니다. 1KB 요청에 100MB 응답이 나가는 워크로드라면 응답이 LB 대역폭 대부분을 소모합니다. 접속자가 늘수록 LB 처리량이 선형으로 증가하고, 백엔드 서버를 늘려도 LB 자체가 처리량의 상한이 됩니다.

L7 라우팅이나 SSL 종단이 필요한 표준 웹 서비스에서는 프록시 방식이 적합합니다. 하지만 응답 트래픽이 크거나 낮은 레이턴시가 중요한 워크로드에서는 구조적인 한계가 있습니다. 응답까지 LB를 경유하는 구조 자체가 병목이 되기 때문입니다. 응답 트래픽을 LB에서 분리해 서버가 클라이언트에게 직접 응답하게 하면 이 문제를 해결할 수 있습니다. 이것이 Load Balancer(DSR)의 출발점입니다.

선 긋기

comparison_900.png

두 방식의 차이는 응답 경로에 있습니다. Load Balancer(DSR)은 요청은 LB를 경유하되, 응답은 LB를 우회하는 비대칭 구조로 동작합니다. IP는 그대로 두고 L2 레벨에서 목적지 MAC만 변경해 서버로 전달하기 때문에 SNAT/DNAT를 수행하지 않습니다. 덕분에 서버에서 클라이언트 원본 IP를 그대로 확인할 수 있어, X-Forwarded-For나 Proxy Protocol 없이도 로깅과 접근 제어가 가능합니다.

세션 분산은 5-tuple(소스 IP/포트, 목적지 IP/포트, 프로토콜) 기반이 기본값입니다. 세션 지속성을 활성화하면 소스 IP 기반으로 전환되어, 동일 클라이언트의 요청이 항상 같은 서버로 전달됩니다.

세션_지속성_비교.png 세션 지속성 설정: 사용 안 함 (5-Tuple Hash) vs 사용 (SOURCE_IP Hash)

단, 비대칭 구조 특성상 서버 측 설정이 필요합니다. 서버는 VIP로 들어온 요청을 받아 VIP를 출발지로 클라이언트에 직접 응답해야 하기 때문입니다. 이를 위해 lo 인터페이스에 VIP를 /32로 바인딩하고, ARP 충돌 방지를 위한 커널 파라미터(arp_ignore=1, arp_announce=2)를 설정해야 합니다.

제약 안에서의 설계

XDP로 커널 앞단에서 패킷을 처리하는 방식을 선택했습니다. 커널 네트워크 스택 진입 전 단계에서 패킷을 처리해 오버헤드를 최소화할 수 있습니다. 개발 과정에서는 여러 제약이 따랐습니다.

XDP 프로그램은 동적 자료구조를 사용할 수 없고 지정된 MAP 형태의 자료구조만 사용해야 하는 제약이 있습니다. 또한, 커널에 로드하는 시점에 BPF Verifier의 검증을 통과해야 합니다. 패킷 데이터에 접근하는 모든 지점에 경계 검사를 명시해야 하고, 하나라도 누락되면 로드가 거부되는데, 거부 사유 로그가 직관적이지 않아 원인을 찾는 데 시간이 걸렸습니다. 또한 instruction 수 제한으로 복잡한 처리를 분리해야 했고, 헬스체크 probe 송신처럼 패킷을 능동적으로 생성하는 작업은 XDP에서 처리할 수 없었습니다.

이를 해결하기 위해 역할을 분리했습니다. 무거운 계산과 능동적인 처리는 유저스페이스의 애플리케이션 레이어가 담당하고, 커널 레이어에서는 BPF MAP 조회만 수행합니다. 멤버 선택에 필요한 해시 데이터와 헬스체크 정보는 유저스페이스에서 미리 계산해 BPF MAP에 저장하고, 패킷 경로에서는 이를 읽기만 합니다. 데이터 경로가 단순해져 검증이 수월해지고 성능도 향상됐습니다.

조용히 동작하는 것들

healthcheck_routing_900.png

클라이언트의 요청은 LB를 경유해 서버로 전달됩니다. VXLAN으로 캡슐화해 멤버 서버로 전송하며, 서버의 응답은 LB를 거치지 않고 클라이언트에게 직접 전달됩니다.

멤버 상태는 ICMP, TCP, HTTP 프로토콜로 주기적으로 점검합니다.

헬스체크.png 헬스체크 설정 화면 — 프로토콜, 주기, 응답 대기 시간, 재시도 횟수 설정

프로토콜과 주기, 재시도 횟수는 콘솔에서 설정할 수 있습니다. 장애가 감지된 멤버는 자동으로 분산 대상에서 제외되고, 복구되면 다시 포함됩니다. 멤버 선택은 일관성 해싱(Consistent Hashing) 기반으로 동작하기 때문에, 여러 LB 노드가 Active-Active로 구성되어도 노드 간 세션 상태 동기화 없이 동일한 분산 결정을 내릴 수 있습니다. Floating IP를 연결하면 외부 네트워크 접근도 가능하며, 멤버는 동일 서브넷 내 인스턴스만 등록할 수 있습니다.

두 가지 선택지

Load Balancer(DSR)은 L4(TCP, UDP)만 지원합니다. L7 라우팅이나 SSL 종단이 필요한 서비스에는 기존 프록시 방식 LB가 적합하며, 두 방식을 워크로드 특성에 맞게 선택해 사용할 수 있습니다.

특히 응답 트래픽이 큰 서비스에 적합합니다. 미디어 스트리밍, 대용량 파일 다운로드, 게임 서버가 대표적인 사용 사례입니다. 클라이언트 원본 IP를 서버에서 직접 확인해야 하는 경우에도 별도 헤더 파싱 없이 활용할 수 있습니다. 프로젝트당 DSR 10개, DSR당 멤버 30개의 쿼터가 적용됩니다.

Load Balancer(DSR)은 XDP/eBPF 기반 커널 단 기술을 상용 네트워크 서비스에 적용한 결과물입니다. 프록시 방식 대비 처리 성능을 높였으며, 워크로드 특성에 맞는 LB 선택이 가능해졌습니다. 모니터링과 통계 집계 기능을 보완 중이며, 운영 가시성을 높이는 방향으로 계속 발전시킬 계획입니다. Load Balancer(DSR)은 NHN Cloud에서 운영 중입니다.

참고 용어

용어설명
XDP(eXpress Data Path)커널 앞단에서 패킷을 처리하는 고성능 기술. DSR의 데이터플레인 핵심입니다.
eBPF(extended Berkeley Packet Filter)커널에서 안전하게 실행되는 프로그램 작성 기술. XDP 구현의 기반입니다.
VXLAN(Virtual Extensible LAN)L2를 L3 위에서 캡슐화하는 터널링 프로토콜. LB가 멤버로 패킷을 전달할 때 사용됩니다.
일관성 해싱(Consistent Hashing)노드 변경 시 기존 세션 재배치를 최소화하는 분산 알고리즘. Active-Active 구조의 기반입니다.
BPF MAPeBPF 프로그램의 데이터 저장·조회 자료구조. 세션·멤버·분산 테이블을 관리합니다.
Control Plane / Data Plane제어(정책 결정, 헬스체크)와 전달(패킷 처리) 역할의 분리 구조. 데이터 경로를 단순하고 빠르게 유지합니다.

NHN Cloud_meetup banner_footer_mint_900.png