기존 프록시 방식 로드 밸런서(LB)의 응답 트래픽 병목 현상을 해결하기 위해 DSR 방식 도입을 설명함
DSR은 요청은 LB 경유, 응답은 서버 직접 전달하는 비대칭 구조로 응답 성능 개선을 목표로 함
XDP/eBPF 기반으로 커널 앞단에서 패킷 처리하여 처리 성능 향상을 달성함
L4만 지원하며, 서버 측 설정 및 XDP 제약 사항 극복이 필요함
기존 프록시 방식 로드 밸런서(LB)는 클라이언트-LB-서버 간 양방향 연결 종단으로 인해 응답 트래픽이 클 경우 LB 자체의 대역폭이 병목이 되는 구조적 한계를 가집니다. 반면, DSR(Direct Server Return)은 요청 트래픽만 LB를 경유시키고, 응답 트래픽은 서버에서 클라이언트로 직접 전달하는 비대칭 라우팅 방식을 채택합니다. 이로써 LB의 처리량 상한선(Throughput Ceiling)을 크게 확장하고, 특히 대용량 응답 트래픽 워크로드에서 레이턴시(Latency)를 획기적으로 개선할 수 있습니다. L7 라우팅이나 SSL 종단이 필요 없는 L4 환경에 적합합니다.
DSR 구현에 XDP(eXpress Data Path)를 채택하여 커널 네트워크 스택 진입 전 패킷 처리를 수행함으로써 오버헤드를 최소화했습니다. XDP는 고성능 데이터 플레인(High-performance Data Plane)을 제공하지만, 동적 자료구조 사용 불가 및 BPF Verifier의 엄격한 검증 통과라는 제약이 따릅니다. 또한, instruction 수 제한으로 복잡한 로직 처리가 어렵고, XDP 자체적으로는 패킷 생성이 불가능합니다. 이러한 제약을 극복하기 위해 Control Plane과 Data Plane을 분리하여, BPF MAP 조회만 담당하는 커널 레이어와 실제 계산 및 패킷 생성을 담당하는 유저스페이스 애플리케이션 레이어로 역할을 나눴습니다.
DSR의 비대칭 라우팅 구조는 서버 측에 추가적인 설정 작업을 요구합니다. 서버는 LB로부터 받은 요청의 출발지 IP를 그대로 유지한 채, 응답 패킷의 출발지 IP(Source IP)를 VIP(Virtual IP)로 설정하여 클라이언트에 직접 전달해야 합니다. 이를 위해 서버의 lo 인터페이스에 VIP를 /32로 바인딩하고, ARP 프로토콜의 동작을 제어하기 위한 커널 파라미터(arp_ignore=1, arp_announce=2) 설정이 필수적입니다. 이러한 설정은 서버가 클라이언트의 원본 IP를 직접 확인할 수 있게 하여, 별도의 헤더 파싱 없이 접근 제어 및 로깅을 용이하게 합니다.
기본적으로 DSR은 5-tuple(소스 IP/포트, 목적지 IP/포트, 프로토콜) 기반으로 세션을 분산합니다. 세션 지속성(Session Persistence) 활성화 시 소스 IP 기반으로 전환되어, 동일 클라이언트의 요청이 항상 같은 백엔드 서버로 전달되도록 보장합니다. 멤버 서버의 상태는 ICMP, TCP, HTTP 프로토콜을 통해 주기적으로 점검하며, 장애 감지 시 자동으로 분산 대상에서 제외하고 복구 시 다시 포함시키는 자동화된 헬스체크(Automated Health Check) 기능을 제공합니다. 또한, 일관성 해싱(Consistent Hashing) 기반의 멤버 선택은 여러 LB 노드가 Active-Active로 구성되어도 노드 간 세션 상태 동기화 없이 일관된 분산 결정을 내릴 수 있게 합니다.
Load Balancer(DSR)는 L4(TCP, UDP) 트래픽 처리에 특화되어 있으며, 특히 미디어 스트리밍, 대용량 파일 다운로드, 게임 서버와 같이 응답 트래픽이 크거나 낮은 레이턴시가 중요한 워크로드에 적합합니다. 클라이언트 원본 IP를 직접 확인해야 하는 경우에도 유용하게 활용될 수 있습니다. 현재 프로젝트당 DSR 10개, 멤버 30개의 쿼터가 적용되어 있습니다. NHN Cloud는 향후 모니터링 및 통계 집계 기능 강화와 운영 가시성 확보를 통해 DSR의 활용성을 더욱 높여나갈 계획입니다.