[Nginx] 리버스 프록시와 부하 분산 처리

현대 웹 아키텍처에서 Nginx는 단순한 웹 서버 그 이상의 역할을 수행한다.
특히 백엔드 서버 앞단에서 요청을 중계하는 '프록시'로서의 역할은 보안과 성능 측면에서 필수적이다.
오늘은 프록시의 두 종류인 리버스(Reverse)와 포워드(Forward)의 차이점부터 시작해, 실무에서 마주하게 되는 헤더 처리, 버퍼링, 그리고 로드 밸런싱까지 깊이 있게 정리해 본다.

 

1. 프록시의 두 얼굴: Forward vs Reverse

프록시(Proxy)는 말 그대로 '대리인'이다. 하지만 누구를 대리하느냐에 따라 그 성격이 완전히 달라진다.

포워드 프록시 (Forward Proxy)

클라이언트가 외부 인터넷에 연결될 때 거치는 서버다. 클라이언트가 "나 구글 가고 싶어"라고 프록시에게 말하면, 프록시가 대신 구글에 가서 데이터를 가져온다. 주로 내부 망에서 외부로 나가는 요청을 제한하거나(사내 보안), 캐싱을 통해 익명성을 보장할 때 사용한다.
즉, 서버는 누가 요청했는지(Client)를 모른다.

리버스 프록시 (Reverse Proxy) - Nginx의 주무대

클라이언트가 서버에 요청을 보낼 때, 실제 백엔드 서버가 아닌 리버스 프록시(Nginx)가 요청을 대신 받는다. 클라이언트는 실제 백엔드 서버의 존재를 모른다. 보안 측면에서 매우 유리한데, 백엔드 서버는 오직 Nginx의 요청만 받도록 사설 망에 숨길 수 있기 때문이다.
즉, 클라이언트는 어디로 요청이 가는지(Server)를 모른다.

 

2. 보안과 투명성: 헤더 정보 처리

리버스 프록시 환경에서 백엔드 서버는 직접 클라이언트와 통신하지 않는다. 모든 요청은 Nginx가 보내기 때문에 백엔드 서버 입장에서 접속자 IP는 항상 Nginx의 IP로 찍히게 된다.

X-Forwarded-For (XFF) 헤더

클라이언트의 진짜 정보를 전달하기 위해 Nginx는 HTTP 헤더를 추가한다.

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

• $proxy_add_x_forwarded_for: 기존 XFF 헤더에 현재 프록시를 거친 클라이언트 IP를 추가한다. 프록시가 여러 개일 경우 IP가 쉼표로 나열되어 전체 경로를 파악할 수 있다.
• 주의 사항: 이 헤더는 클라이언트가 직접 조작할 수 있다. 만약 악의적인 사용자가 가짜 IP를 헤더에 넣어 보낸다면 백엔드 서버는 잘못된 정보를 믿게 된다. 따라서 운영 환경에서는 real_ip_module 등을 통해 신뢰할 수 있는 프록시 대역만 필터링하는 등의 틀 구축이 필수적이다.

 

3. 성능의 핵심: 버퍼링과 Keep-alive

Nginx는 백엔드 서버의 자원을 효율적으로 보호하기 위해 네트워크 통신 중간에서 '완충 작용'을 한다.

버퍼링 (Buffering) : 백엔드 스레드 점유 최소화

백엔드 서버(Java, Python 등)는 응답을 매우 빠르게 생성하지만, 클라이언트의 네트워크 환경(모바일 등)은 느릴 수 있다.

• 작동 원리: Nginx는 백엔드로부터 응답을 일단 '빠르게 통째로' 받아버린다(버퍼링). 응답을 다 받으면 백엔드와의 연결을 즉시 끊어버린다. 그 후 Nginx가 느린 클라이언트에게 천천히 응답을 전송한다.
• 효과: 백엔드 서버는 비싼 자원(스레드, 커넥션)을 클라이언트가 다 받을 때까지 기다릴 필요 없이 즉시 다음 업무를 처리할 수 있다.
• 예외: 실시간성이 중요한 서비스(채팅)나 초대용량 스트리밍 서비스에서는 버퍼링을 끄는 것이 유리하다.

Keep-alive

TCP 연결을 매번 새로 맺는 3-way handshake 비용은 매우 크다.
Keep-alive는 한 번 맺은 연결을 일정 시간 유지하여 재사용하는 기술이다.

• 별개의 연결: 클라이언트-Nginx 연결과 Nginx-백엔드 연결은 완전히 별개로 관리된다.
• HTTP/1.1 필수: 백엔드와 Keep-alive를 유지하려면 Nginx 설정에서 proxy_http_version 1.1;과 proxy_set_header Connection ""; 처리가 필요하다.

 

4. WebSocket과 Dynamic Reverse Proxy

WebSocket은 일반적인 HTTP와 달리 양방향 실시간 통신을 지원한다. Nginx가 이를 프록시하려면 Protocol Upgrade 과정이 필요하다.

location /chat {
    proxy_pass http://backend_node;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade; # 핵심: Upgrade 헤더
    proxy_set_header Connection "Upgrade"; # 핵심: Connection 헤더
}

WebSocket은 'Hop-by-hop' 헤더를 사용하기 때문에, 프록시가 이 헤더를 명시적으로 전달해주지 않으면 연결이 끊긴다.
Upgrade와 Connection 헤더를 설정해주는 것이 WebSocket 지원의 핵심이다.

 

 

5. 트래픽의 지휘자: 로드 밸런싱 (Load Balancing)

서버 한 대가 모든 부하를 견딜 수 없을 때, 여러 대의 서버로 트래픽을 나누는 것이 로드 밸런싱의 핵심이다. 이는 시스템의 고가용성(High Availability)과 확장성을 보장한다.

인프라 확장 전략: Scale-Up vs Scale-Out

트래픽이 증가할 때 우리는 두 가지 선택을 할 수 있다.

• Scale-Up (수직 확장): 서버 자체의 성능(CPU, RAM)을 올리는 것. 관리는 쉽지만 물리적 한계가 명확하고 비용이 비약적으로 상승한다.
• Scale-Out (수평 확장): 저렴한 서버를 여러 대 추가하는 것. 로드 밸런서가 필수적이며, 이론상 무한 확장이 가능해 현대 클라우드 환경에서 선호된다.

 

L4 vs L7 로드 밸런싱

구분L4 로드 밸런싱L7 로드 밸런싱

계층	전송 계층 (Transport)	응용 계층 (Application)
기준	IP, 포트(TCP/UDP)	URL, 헤더, 쿠키, 페이로드
특징	데이터 내용을 보지 않아 매우 빠르고 효율적	패킷 내용을 분석해 정교한 분기 가능
Nginx 활용	stream 모듈 사용	http 블록 내 upstream 사용

1. L4 (Layer 4): 전송 계층(TCP/UDP) 정보를 기반으로 나눈다. IP와 포트 번호만 보고 기계적으로 분산하기 때문에 속도가 매우 빠르다. 하지만 패킷 내용을 볼 수 없어 정교한 라우팅은 불가능하다.
2. L7 (Layer 7): 애플리케이션 계층(HTTP/HTTPS) 정보를 기반으로 나눈다. URL 경로, 쿠키 내용, 헤더 정보 등을 보고 분산한다. 특정 사용자 그룹을 특정 서버로 보내는 등 유연한 관리가 가능하다.

Nginx는 주로 L7 로드 밸런서로 동작하며, 서버가 응답하지 않을 때 자동으로 목록에서 제외하는 Health Check 기능을 통해 서비스 중단을 방지한다.

 

Nginx 주요 부하 분산 알고리즘

Nginx는 다양한 방식으로 트래픽을 나눈다. 상황에 맞는 전략 선택이 중요하다.

1. Round Robin (라운드 로빈): 아무 설정이 없을 때의 기본값. 순서대로 돌아가며 요청을 배분한다. 모든 서버 성능이 동일할 때 적합하다.
2. Least Connections (최소 연결): 현재 연결 수가 가장 적은 서버로 요청을 보낸다. 요청마다 처리 시간이 다를 때 효율적이다.
3. IP Hash (IP 해시): 클라이언트의 IP를 해싱하여 특정 서버에 고정한다. Session Sticky가 필요한 경우(예: 로그인 세션 유지) 유용하다.

 

실무 선택 가이드

• 단순 성능 확장이 목표인가? → Scale-Out + L4/L7 LB
• 특정 URL 경로에 따라 서버를 나누어야 하는가? → L7 로드 밸런싱
• 데이터 보안과 전송 효율이 최우선인가? → L4 로드 밸런싱

 

 

6. 마치며

Nginx를 리버스 프록시로 활용하는 것은 단순히 중계 서버를 하나 더 두는 것이 아니다.
백엔드의 리소스를 보호하고, 클라이언트의 느린 속도를 완충하며, 유연한 로드 밸런싱을 통해 중단 없는 서비스를 제공하기 위한 전략적 선택이다.