pile·
네트워크·NHN Cloud MeetupNHN Cloud·

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

NHN Cloud가 XDP/eBPF 기반 커널 단 기술로 만든 DSR(Direct Server Return) 방식 로드 밸런서를 소개한다. 기존 프록시 방식 LB는 요청·응답을 모두 종단·중계해 응답 트래픽이 클수록 LB가 병목이 된다. 이를 요청만 LB를 경유하고 응답은 서버가 클라이언트에 직접 보내는 비대칭 구조로 해결한다. 미디어 스트리밍·대용량 다운로드·게임 서버처럼 응답이 큰 L4 워크로드가 대상이다.

핵심 포인트
  • 프록시 LB는 1KB 요청에 100MB 응답 같은 워크로드에서 응답이 LB 대역폭 대부분을 소모해, 백엔드를 늘려도 LB가 처리량 상한이 된다.
  • DSR은 IP는 그대로 두고 L2에서 목적지 MAC만 바꿔 전달, SNAT/DNAT를 안 해 서버가 클라이언트 원본 IP를 별도 헤더 없이 그대로 확인한다.
  • XDP로 커널 네트워크 스택 진입 전에 패킷을 처리해 오버헤드를 최소화하되, XDP 제약 때문에 무거운 계산은 유저스페이스, 커널은 BPF MAP 조회만 하는 역할 분리로 설계했다.
  • 멤버 선택을 일관성 해싱으로 처리해 여러 LB 노드를 세션 상태 동기화 없이 Active-Active로 구성한다.
  • L4(TCP/UDP)만 지원하며, L7 라우팅·SSL 종단이 필요하면 기존 프록시 LB를 쓰는 이원화 전략을 제시한다.
상세 정리
  • 문제: 프록시 방식은 클라이언트-서버 양쪽 연결을 종단·중계해 응답까지 LB를 경유한다. 응답 트래픽이 크거나 저지연이 중요한 워크로드에서 LB 경유 구조 자체가 병목이 된다.
  • 접근: 응답 트래픽을 LB에서 분리해 서버가 클라이언트에 직접 응답하게 하는 DSR로 방향을 잡았다.
  • 동작 구조: 요청은 LB를 경유하고 응답은 LB를 우회하는 비대칭 구조다. IP를 유지하고 L2 MAC만 바꿔 NAT가 없으므로, X-Forwarded-For나 Proxy Protocol 없이 원본 IP로 로깅·접근 제어가 가능하다.
  • 세션 분산: 기본은 5-tuple(소스 IP/포트, 목적지 IP/포트, 프로토콜) 해시이고, 세션 지속성을 켜면 소스 IP 해시로 전환돼 동일 클라이언트 요청이 항상 같은 서버로 간다.
  • 서버 측 설정: 비대칭 구조라 서버가 VIP로 받은 요청에 VIP를 출발지로 직접 응답해야 한다. 이를 위해 lo 인터페이스에 VIP를 /32로 바인딩하고 ARP 충돌 방지 커널 파라미터(arp_ignore=1, arp_announce=2)를 설정해야 한다.
  • XDP 제약: 동적 자료구조를 못 쓰고 지정된 MAP만 쓸 수 있으며, BPF Verifier 통과를 위해 패킷 접근마다 경계 검사를 명시해야 한다(누락 시 로드 거부, 사유 로그가 불친절). instruction 수 제한으로 복잡한 처리를 분리해야 했고, 헬스체크 probe처럼 능동적으로 패킷을 생성하는 작업은 XDP에서 처리할 수 없었다.
  • 역할 분리 설계: 무거운 계산과 능동 처리는 유저스페이스가, 커널은 BPF MAP 조회만 담당한다. 해시·헬스체크 데이터를 유저스페이스에서 미리 계산해 MAP에 저장하고 패킷 경로에서는 읽기만 해서, 데이터 경로가 단순해져 검증이 쉬워지고 성능도 향상됐다.
  • 패킷 전달·헬스체크: LB는 요청을 VXLAN으로 캡슐화해 멤버 서버로 전송하고 응답은 LB를 거치지 않는다. 멤버 상태는 ICMP·TCP·HTTP로 주기 점검하며 프로토콜·주기·재시도는 콘솔에서 설정한다. 장애 멤버는 자동 제외되고 복구되면 재편입된다.
  • 분산 일관성: 일관성 해싱 기반이라 Active-Active 다중 노드에서도 세션 상태 동기화 없이 동일한 분산 결정을 내린다. Floating IP를 연결하면 외부 접근이 가능하고, 멤버는 동일 서브넷 내 인스턴스만 등록할 수 있다.
  • 적용 경계·쿼터: L4만 지원하고 응답이 큰 서비스(미디어 스트리밍·대용량 다운로드·게임)에 적합하다. 프로젝트당 DSR 10개, DSR당 멤버 30개 쿼터가 있으며 모니터링·통계 집계 기능은 보완 중이다.
왜 읽나대용량 응답·저지연 L4 트래픽을 다루며 프록시 LB 병목을 겪는 인프라·네트워크 엔지니어에게, XDP/eBPF 기반 DSR의 설계 트레이드오프와 서버 설정·제약 레퍼런스.
NHN Cloud Meetup
NHN Cloud 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 네트워크·cloudflare-blogCloudflare Blog·

    Cloudflare Cache Response Rules — 오리진 응답 기반 캐시 제어

    Cloudflare가 오리진 응답이 도착한 뒤 캐시에 쓰이기 직전에 개입하는 Cache Response Rules를 내놨다. 기존 Cache Rules는 요청 단계에서만 동작해, 오리진이 붙인 Set-Cookie·no-cache·ETag 때문에 충분히 캐시 가능한 응답이 오리진으로 되돌아가는 문제를 풀지 못했다. 새 규칙은 응답 헤더를 보고 헤더 제거·캐시 태그 관리·Cache-Control 수정을 수행해, 오리진 수정 없이 캐시 적중률을 끌어올린다.

  2. 네트워크·cloudflare-blogCloudflare Blog·

    Cloudflare Internal DNS 정식 출시 — 사설·공인 DNS 통합 구조

    Cloudflare가 사설(내부)·공인 DNS 해석을 하나의 플랫폼으로 통합하는 Internal DNS를 정식 출시했다. 기존에는 공인 DNS·내부 DNS·클라우드별 DNS가 제각기 다른 보안 정책으로 흩어져 공통 컨트롤 플레인이 없었고, split-horizon 구성은 병렬 시스템을 수동 동기화하다 drift로 장애를 냈다. 새 제품은 단일 API·감사 로그·정책 계층으로 이를 합치고, 1.1.1.1 인프라 위에서 하드웨어 없이 동작하며 Enterprise는 Gateway에 무료 포함된다.

  3. 네트워크·cloudflare-blogCloudflare Blog·

    .AL TLD DNSSEC 장애 분석과 EDE 33 투명성 코드 도입

    2026년 7월 3일 알바니아(.AL) TLD의 DNSSEC 키 롤오버 실수로 알바니아 정부, 은행, 미디어 등 모든 .AL 도메인이 약 5시간 동안 다운된 사건을 다룬다. Cloudflare가 Negative Trust Anchor(NTA)로 빠르게 대응했지만, 기존 NTA 응답이 정상 검증 응답과 구분되지 않는 투명성 문제가 있었다. 이를 계기로 NTA 적용 여부를 DNS 응답에 직접 표시하는 EDE 33 코드가 IANA에 공식 등록됐다.

    #network-security#dnssec#dns+2