In-Line은 트래픽 경로에 로드밸런서를 배치하고, One-Arm은 기존 네트워크에 로드밸런서를 곁가지로 연결하는 구성을 가리킵니다. 제품별 용어가 다를 수 있습니다. 배치만으로 Proxy 또는 DSR 동작이 결정되지는 않으며, 요청과 응답이 어디로 가는지가 핵심입니다.
배치 방식 비교
| 항목 | In-Line | One-Arm |
|---|---|---|
| 설계 출발점 | 어떤 트래픽이 장비를 통과하는가 | 어떤 목적지의 트래픽을 장비로 보내는가 |
| 응답 경로 | 라우팅·브리지·변환 설정으로 확인 | 우회 응답이 의도한 동작인지 별도 확인 |
| 장애 검토 | 장비·링크 장애가 통과 트래픽에 미치는 영향 | VIP 도달성, 우회 경로와 변환 상태의 영향 |
“One-Arm이면 L3 부하가 항상 두 배”처럼 배치 이름만으로 성능을 계산할 수는 없습니다. 인터페이스별 실제 트래픽, 요청·응답 크기, 처리 방식과 장비 용량을 봐야 합니다.
주소를 적어 보면 응답 우회가 보입니다
다음은 주소 흐름을 이해하기 위한 가상 예제입니다. 클라이언트 C가 VIP V로 요청하고 로드밸런서가 실제 서버 R로 목적지를 바꾼다고 가정합니다.
요청: C → V → [로드밸런서: 목적지 변환] → R
응답: R → 기본 게이트웨이 → C ?
이때 서버가 응답을 로드밸런서가 아닌 다른 게이트웨이로 보내면, 연결을 추적하는 장비에서 필요한 역변환이 이뤄지지 않을 수 있습니다. 서버의 라우팅을 조정하거나 장비가 제공하는 SNAT 등으로 응답을 되돌리는 방식을 검토합니다. 이는 NAT 구성의 예이며, 응답 우회를 의도하는 DSR과는 전제가 다릅니다.
SNAT을 선택할 때 확인할 대가
SNAT으로 서버가 보는 요청 출발지를 로드밸런서 주소로 바꾸면 응답을 돌려받기 쉬워질 수 있습니다. 대신 원본 클라이언트 IP 가시성, 사용 가능한 변환 포트, 로깅·접근 제어 영향도 확인해야 합니다. HTTP 헤더로 원본 주소를 전달하는 방식은 애플리케이션과 신뢰할 프록시 설정이 필요하며 모든 프로토콜에 적용되지 않습니다.
구성 전 점검표
- 클라이언트·VIP·서버의 주소와 서브넷을 적습니다.
- 요청과 응답을 따로 그리고 각 구간의 출발지·목적지 변환을 표시합니다.
- 서버·로드밸런서·중간 방화벽의 라우팅과 상태 추적 조건을 확인합니다.
- 정상 요청, 서버 장애, 로드밸런서 장애를 각각 검증합니다.
- TCP 연결뿐 아니라 실제 서비스 응답과 운영 로그를 확인합니다.
이 글은 배치 설계에 집중합니다. 연결 분리와 직접 응답의 차이는 별도의 Proxy·DSR 비교 글에서 이어서 확인할 수 있습니다. 아래 도식은 당시 작성한 배치 예시이며 모든 제품의 기본 동작을 의미하지 않습니다.
함께 읽기
Proxy와 DSR의 패킷 처리 차이에서 관련 개념을 이어서 확인할 수 있습니다.
참고 자료
기존 기록의 화면과 도식
최초 발행 당시의 참고 자료입니다. 최신 설정은 위 설명과 해당 버전의 공식 문서를 확인하세요.


LoadBalancer In-Line Architecture -2
