DSR
DSR(Direct Server Return, 직접 서버 응답) 은 로드밸런서(L4) 구성 방식 중 하나로, 클라이언트 → 로드밸런서 → 서버로 요청은 거치되, 서버 → 클라이언트 응답은 로드밸런서를 거치지 않고 서버가 직접 돌려보내는 방식이다. 응답 트래픽이 로드밸런서를 우회하므로 로드밸런서의 부하가 크게 줄어든다. 그래서 응답 데이터가 요청보다 훨씬 큰 서비스(영상 스트리밍, 대용량 다운로드 등)에서 강력한 성능을 낸다.
왜 필요한가
일반적인 로드밸런싱(NAT/Proxy 방식)에서는 요청과 응답이 모두 로드밸런서를 통과한다.
[Client] → [LB] → [Server]
[Client] ← [LB] ← [Server] ← 응답도 LB를 거침
웹 트래픽은 보통 요청은 작고(수백 바이트), 응답은 크다(이미지·영상 수 MB). 이 비대칭 때문에 응답까지 LB가 처리하면 LB가 병목이 된다. DSR은 이 응답 경로에서 LB를 빼버린다.
[Client] → [LB] → [Server]
[Client] ←──────── [Server] ← 응답은 서버가 직접
요청만 LB를 거치므로, LB는 훨씬 많은 연결을 감당할 수 있고 지연(latency)도 줄어든다.
동작 방식
핵심은 VIP(Virtual IP)를 서버에도 심어두는 것이다.
- 클라이언트가 VIP로 요청을 보낸다.
- LB는 패킷의 목적지 IP(VIP)는 그대로 두고, L2 목적지 MAC 주소만 실제 서버의 MAC으로 바꿔 전달한다. (MAT, MAC Address Translation)
- 서버는 자신의 루프백 등에 VIP를 가지고 있어, 목적지가 VIP인 패킷을 자기 것으로 받아들여 처리한다.
- 서버는 응답의 출발지 IP를 VIP로 해서 클라이언트에게 직접 보낸다.
클라이언트 입장에서는 요청을 보낸 VIP에서 응답이 온 것처럼 보이므로 정상 동작한다.
제약 사항
DSR은 빠른 대신 할 수 있는 일이 제한적이다. LB가 응답(돌아오는 트래픽)을 보지 못하기 때문이다.
| 항목 | DSR에서의 한계 |
|---|---|
| 동작 계층 | L4까지만. L7 처리 불가 |
| SSL Offload | 불가 — 양방향 트래픽을 모두 봐야 하는데 응답을 못 봄 |
| WAF / L7 검사 | 불가 — 같은 이유 |
| 세션 유지(persistence) | Source/Destination IP 기반만 가능, 쿠키 기반 불가 |
| 서버 설정 | 모든 서버에 VIP 바인딩 + ARP 응답 억제 설정 필요 |
특히 SSL Offload와 DSR은 같이 쓸 수 없다. SSL을 LB에서 처리하려면 LB가 요청과 응답을 모두 봐야 하는데, DSR은 응답이 LB를 우회하기 때문이다.
다른 방식과 비교
| 방식 | 응답 경로 | 동작 계층 | 특징 |
|---|---|---|---|
| DSR | 서버 → 클라이언트 직접 | L4 | 최고 성능, 기능 제한 |
| NAT | 서버 → LB → 클라이언트 | L4 | 무난, LB가 응답도 처리 |
| Proxy(L7) | 서버 → LB → 클라이언트 | L7 | SSL Offload·WAF 등 풍부한 기능, LB 부하 큼 |
DSR → Offload 전환
DSR은 성능은 좋지만 LB가 응답을 못 보기 때문에 SSL Offload·WAF·쿠키 세션 같은 L7 기능을 전혀 쓸 수 없다. 보안 검사나 인증서 중앙 관리가 필요해지면 DSR을 포기하고 LB가 트래픽을 종단(terminate)하는 Proxy/Offload 구조로 전환하게 된다. 대신 LB가 양방향 트래픽을 모두 처리하므로 LB 용량(성능)이 더 필요해진다.