Daily CS) Reverse Proxy

goldenGlow_21·2025년 4월 17일

Daily CS

목록 보기

42/50

Reverse Proxy

proxy server that appears to any client to be an ordinary web server, but in reality merely acts as an intermediary that forwards the client's requests to one or more ordinary web servers

오늘의 주제는 리버스 프록시. 프로젝트 중이었나... 자료조사를 하던 중 연관 개념으로 나왔던 걸 따로 기록해뒀는데, 따로 공부해볼 기회를 마련해보고자 오늘의 주제로 삼았다.

1. 프록시의 기본 개념과 종류

1.1 프록시 서버란?

프록시(Proxy) 서버는 클라이언트와 서버 사이에 위치해, 클라이언트의 요청을 대신 처리하거나 서버의 응답을 중계하는 중간 매개체 역할을 수행하는 서버다. 즉, 클라이언트가 직접 목적지 서버에 연결하는 것이 아니라, 프록시 서버를 통해 간접적으로 통신하는 구조를 만든다.

프록시는 요청이 어떤 방향으로 흐르느냐에 따라 Forward Proxy(정방향 프록시) 와 Reverse Proxy(역방향 프록시) 로 나뉜다. 이를 이해하는 것이 프록시 개념의 핵심이다.

기본적인 작동 방식은 다음과 같다:

클라이언트 → 프록시 서버 → 실제 서버
실제 서버의 응답 → 프록시 서버 → 클라이언트

프록시 서버는 다음과 같은 작업을 수행할 수 있다.

요청 필터링
캐싱
트래픽 기록 (로깅)
콘텐츠 압축 및 해석
TLS 종료 및 복호화 처리

1.2 Forward Proxy vs Reverse Proxy

구분	*Forward Proxy*	*Reverse Proxy*
위치	클라이언트 앞단	서버 앞단
대상	클라이언트가 외부와 통신할 때 사용	클라이언트가 서버에 접근할 때 서버 측에서 사용
사용 주체	사용자, 기업 내부망 사용자	서버 운영자, 서비스 제공자
주요 목적	접근 차단 우회, 캐싱, 익명성 보장	부하 분산, 보안강화, SSL 종료, 백엔드 보호
예시	웹 필터링 프록시, Tor, Squid	NGINX Reverse Proxy, Apache mod_proxy, Cloudflare

Forward Proxy

사용자는 프록시 서버를 통해 외부의 웹사이트에 접근.
주로 기업/학교 내부에서 인터넷 필터링, 국가 간 차단 우회 등의 목적.
클라이언트의 IP를 숨기고 대신 요청함.
대표 예: Squid, Tor Browser

Reverse Proxy

외부 클라이언트는 실제 서버가 아닌 프록시 서버에 요청을 보냄.
리버스 프록시는 해당 요청을 적절한 백엔드 서버로 전달.
부하 분산, SSL 처리, 웹 애플리케이션 방화벽(WAF), 정적 파일 캐싱 등 고급 기능 수행.
대표 예: NGINX, Apache HTTPD (mod_proxy), HAProxy, Cloudflare

1.3 프록시 서버의 일반적인 사용 목적

프록시 서버는 사용 위치와 역할에 따라 다양한 기능을 제공하며, 대표적인 목적은 아래와 같다:

1) 접근 제어 및 보안

특정 도메인, 포트, IP 주소에 대한 접근을 제한하거나 허용할 수 있다.
기업 내부망에서는 Forward Proxy로 불필요한 외부 접속을 차단하는 데 활용되며, Reverse Proxy는 공격자에게 실제 서버의 IP를 노출하지 않도록 보호하는 데 기여한다.

2) 캐싱과 성능 최적화

프록시 서버는 자주 요청되는 데이터를 캐시하여, 매번 원본 서버에 접근할 필요 없이 빠르게 응답 가능.
Reverse Proxy에서는 정적 콘텐츠(이미지, JS, CSS 등)를 캐싱해 백엔드 서버 부하를 줄인다.

3) 익명성 보장

Forward Proxy는 사용자의 IP를 숨기고 자신이 대신 요청함으로써 사용자의 익명성을 보호할 수 있다.
이는 검열 우회, 개인 정보 보호, 위치 기반 콘텐츠 우회에 활용된다.

4) 트래픽 로깅 및 모니터링

프록시 서버는 모든 요청/응답을 중간에서 관찰할 수 있어 트래픽 분석, 보안 로그 수집에 유리하다.
보안사고 대응 및 컴플라이언스 준수를 위한 모니터링 용도로도 활용됨.

5) 로드 밸런싱

Reverse Proxy는 여러 백엔드 서버 간에 요청을 분산시켜 서비스 가용성과 확장성을 향상시킬 수 있다.
라운드 로빈, 최소 연결 수 방식 등 다양한 로드 밸런싱 전략 적용 가능.

2. 리버스 프록시의 구조와 동작 원리

2.1 클라이언트 요청 처리 흐름

리버스 프록시는 클라이언트의 요청을 최종 목적지 서버가 아닌 프록시 서버가 먼저 수신한다. 이를 통해 서버 인프라 뒤편에 위치한 백엔드 서버들의 노출을 막고, 트래픽을 효율적으로 관리할 수 있다.

동작 흐름 요약:

클라이언트가 도메인 요청 (예: https://example.com)
- DNS는 실제 백엔드 서버가 아닌 프록시 서버의 IP 주소를 반환.
리버스 프록시가 클라이언트의 요청을 수신
- HTTP 요청 헤더, 쿠키, 요청 메서드 등 분석.
리버스 프록시가 요청을 내부적으로 적절한 백엔드 서버로 전달
- URL 패턴, Host 헤더, 로드 밸런싱 알고리즘 등에 따라 선택.
백엔드 서버가 응답 반환 → 프록시 서버가 응답을 수신
프록시 서버가 응답을 클라이언트에게 전달
- 필요 시 콘텐츠 압축, 캐시 처리, 헤더 가공 등도 수행.

주의: 클라이언트 입장에선 백엔드 서버의 존재를 인지하지 못함. 오직 프록시만 보임.

예시:

https://api.example.com → Reverse Proxy → 내부의 http://127.0.0.1:3000 API 서버
https://static.example.com → Reverse Proxy → 내부의 Nginx 정적 파일 서버

2.2 백엔드 서버와의 연결 관리 방식

리버스 프록시는 백엔드와의 세션/연결을 어떻게 유지하고 관리하느냐에 따라 성능과 안정성이 좌우된다. 일반적인 연결 방식은 다음과 같다:

1) Keep-Alive 연결 유지

프록시 서버는 백엔드와의 HTTP 연결을 재사용하기 위해 Keep-Alive를 활용.
요청마다 TCP 세션을 새로 여는 비용을 줄여줌.
NGINX, Apache, HAProxy는 keepalive_requests, keepalive_timeout 등의 설정 지원.

2) 커넥션 풀링 (Connection Pooling)

프록시가 미리 여러 개의 TCP 연결을 열어두고 요청이 들어오면 재활용.
Node.js, Python WSGI 서버, Java 톰캣 등과 연동 시 중요.
고속 처리와 낮은 레이턴시 확보에 기여.

3) 세션 핀ning (Session Affinity)

동일한 클라이언트의 요청이 항상 같은 백엔드로 전달되도록 유지.
로그인 상태, 세션 기반 처리에 유용.
쿠키 기반 세션 스티키(sticky session), IP 기반 라우팅 등으로 구현.

주의: 백엔드 서버가 여러 개일 경우, 세션 유지 로직이 없는 상태에서 라운드 로빈 등 단순 분산을 적용하면 사용자 인증 등에서 문제가 발생할 수 있음.

2.3 DNS 및 포트 매핑과의 관계

리버스 프록시는 보통 클라이언트에게 도메인으로 접근하게 하며, 이는 DNS 및 포트 설정과 밀접한 연관이 있다.

2.3.1 DNS 구성

프록시 서버는 여러 도메인 또는 서브도메인을 하나의 IP 주소로 받아 처리 가능.
실제 운영에서는 하나의 서버가 example.com, api.example.com, admin.example.com 등 여러 도메인을 동시에 수신하도록 구성됨.
리버스 프록시는 Host 헤더를 기반으로 내부 라우팅을 결정.

# 예시: /etc/hosts 또는 DNS 설정
203.0.113.1    example.com
203.0.113.1    api.example.com

2.3.2 포트 매핑 및 NAT 관계

기본적으로 리버스 프록시는 80(HTTP), 443(HTTPS) 포트에서 수신.
내부 백엔드 서버는 보통 8080, 3000, 5000 등의 비표준 포트에서 실행.
이를 통해 외부에서는 단일 포트(80/443)로 접근하되, 내부적으로는 다양한 포트로 트래픽이 전달됨.

# 예시: NGINX 리버스 프록시 설정
location /api/ {
    proxy_pass http://localhost:3000/;
}

팁: 리버스 프록시와 NAT(Network Address Translation)를 함께 사용할 경우, 내부 IP와 포트를 외부에 노출시키지 않고도 효과적인 서비스 분산이 가능하다.

3. 리버스 프록시의 주요 기능

3.1 SSL 종단 처리 (SSL Termination)

리버스 프록시는 HTTPS 통신의 SSL/TLS 암호화를 종단(Terminate) 처리함으로써, 백엔드 서버와의 연결은 암호화되지 않은 HTTP로 유지될 수 있도록 한다. 이는 보안과 성능의 균형을 맞추는 중요한 기법이다.

클라이언트와 프록시 간 암호화 유지

클라이언트와의 통신은 HTTPS로 유지되며, SSL 인증서 및 키는 프록시 서버(Nginx, HAProxy 등)에 배치된다. 프록시가 SSL 암호화를 해제(decrypt)하고, 내부 네트워크로는 HTTP로 요청을 전달한다.

백엔드 단순화 및 부하 감소

백엔드 서버는 SSL 처리 로직이 필요 없으며, TLS 핸드셰이크에 따른 CPU 부하도 감소한다. 결과적으로 서버 응답 성능이 향상될 수 있다.

인증서 중앙관리의 장점

모든 SSL 인증서를 리버스 프록시에 집중 배치함으로써, 갱신과 관리가 단순화된다. Let’s Encrypt를 통한 자동 갱신 구성도 용이하다.

단, 내부 네트워크의 보안이 약한 경우에는 프록시 이후 구간도 TLS로 구성하는 "end-to-end encryption"이 고려되어야 한다.

3.2 로드 밸런싱 (Load Balancing)

리버스 프록시는 클라이언트 요청을 여러 백엔드 서버로 분산시켜 서비스의 확장성과 가용성을 확보할 수 있게 한다. 이를 로드 밸런싱이라고 한다.

정적 로드 밸런싱 방식
- 라운드 로빈: 요청을 순서대로 각 서버에 분산. 구성 간단하지만 서버 상태는 고려하지 않음.
- 가중치 기반 (Weighted Round Robin): 성능이 높은 서버에 더 많은 요청 할당.
동적 로드 밸런싱 방식
- 리스폰스 시간 기반: 서버 응답 시간에 따라 트래픽 분산.
- Health Check 기반: 장애 서버는 자동 제외. HAProxy, Traefik, Envoy 등에서 지원.
세션 유지 기능 (Session Persistence)
- 로그인 등의 상태 정보를 유지해야 할 경우 동일 클라이언트의 요청을 항상 같은 서버로 보내는 기능.
- 쿠키, IP, URL 패턴 등을 기준으로 설정할 수 있다.

로드 밸런싱은 단순 트래픽 분산 외에도, 장애 대응 및 성능 최적화 전략의 핵심 구성요소

3.3 캐싱 및 정적 콘텐츠 오프로드

리버스 프록시는 반복적으로 요청되는 정적 리소스(HTML, CSS, JS, 이미지 등)를 자체적으로 캐시하거나 직접 제공하여 백엔드 서버의 부담을 줄일 수 있다.

정적 콘텐츠 오프로드

자주 요청되는 정적 파일을 프록시 서버가 직접 응답함으로써 백엔드 서버의 응답 필요성을 제거한다. NGINX의 location 디렉티브로 구현 가능하며, CDN과의 조합도 가능하다.

동적 콘텐츠 캐싱

로그인 상태에 영향을 받지 않는 API 응답 등은 캐시 저장 후 일정 시간 동안 동일 응답을 제공할 수 있다. 이는 백엔드 처리 비용을 절감하고 응답 속도를 향상시킨다.

캐시 무효화 및 조건부 처리

캐시된 데이터가 일정 주기나 조건에 따라 무효화되도록 설정 가능.
ETag, Last-Modified 등의 HTTP 헤더 기반 조건부 캐싱을 통해 효율적인 전송 가능.

과도한 캐싱은 데이터 불일치를 야기할 수 있으므로 신중한 정책 수립이 요구됨

3.4 요청 필터링 및 접근 제어

리버스 프록시는 네트워크 수준에서 접근을 제어하거나 요청의 유효성을 검증하는 보안 기능을 수행할 수 있다.

IP 기반 접근 제한
- 특정 IP 주소 대역만 허용하거나, 블랙리스트 지정 가능.
- NGINX에서는 allow, deny 지시어 사용.
URL/패턴 기반 필터링
- 의심스러운 경로(/admin, /shell, /phpmyadmin 등)에 대한 차단.
- User-Agent, Referer 등을 기반으로 필터링 가능.
DDoS 또는 봇 차단 기능
- 요청 수 제한(Rate Limiting), 특정 시간 내 요청 횟수 제한.
- Cloudflare, AWS WAF, NGINX Plus 등의 상용 솔루션과 연동 시 고급 필터링 가능.
HTTP 인증 처리
- 프록시에서 Basic 인증, 토큰 기반 인증 등의 1차 인증을 걸 수 있음
- 백엔드 서버에 전달 전에 인증 여부를 사전 확인할 수 있음.

4. 주요 리버스 프록시 소프트웨어

4.1 NGINX의 리버스 프록시 구성

NGINX는 경량화된 고성능 HTTP 서버로 출발했지만, 리버스 프록시 기능에서도 매우 널리 활용된다. 낮은 메모리 사용량과 높은 처리 성능, 간단한 설정 방식 덕분에 대규모 서비스에서도 사용된다.

기본 설정 예시
- /etc/nginx/sites-available/default 파일에서 location 블록 내에 proxy_pass 지시어를 통해 리버스 프록시를 구성할 수 있다.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

기능 확장
- proxy_cache, proxy_buffering, proxy_redirect 등을 통해 캐싱과 리디렉션 제어 가능
- SSL 종단 처리를 위해 listen 443 ssl 및 ssl_certificate, ssl_certificate_key 설정 추가
활용 사례
- 마이크로서비스 아키텍처에서 프론트로 요청을 받고, 내부 API 게이트웨이 역할 수행
- 정적 리소스는 직접 서빙하고, 동적 요청은 백엔드에 전달하는 하이브리드 구성 가능

4.2 Apache HTTPD의 mod_proxy 설정

Apache HTTP Server는 오랜 역사와 광범위한 호환성을 가진 웹 서버이며, mod_proxy 모듈을 활성화하여 리버스 프록시로 사용할 수 있다. 보통 레거시 시스템이나 특정 CMS 기반 시스템에서 많이 활용된다.

mod_proxy 활성화
- Apache의 모듈은 a2enmod 명령어를 통해 활성화 가능하다.

sudo a2enmod proxy
sudo a2enmod proxy_http

기본 설정 예시
- 000-default.conf 혹은 별도 VirtualHost 파일 내에 아래와 같이 작성한다.

<VirtualHost *:80>
    ServerName example.com

    ProxyPreserveHost On
    ProxyPass / http://localhost:8080/
    ProxyPassReverse / http://localhost:8080/
</VirtualHost>

기능 특성
- Apache는 프록시 요청마다 프로세스를 생성하는 구조이므로 NGINX 대비 메모리 부담이 클 수 있다.
- 다만 .htaccess나 다양한 모듈 조합을 통해 세세한 제어가 가능하다는 점에서 유연성이 높다.
활용 사례
- LAMP 스택과 함께 사용되는 서비스에서 PHP 애플리케이션 앞단 리버스 프록시 역할
- 일부 모듈(mod_security, mod_rewrite)과의 연계로 보안 정책 적용에 유리

4.3 HAProxy의 TCP/HTTP 레벨 프록싱

HAProxy는 고성능 로드 밸런서이자 리버스 프록시로, 특히 L4(TCP), L7(HTTP) 레벨 모두 지원하는 점이 특징이다. 다수의 연결을 효율적으로 관리할 수 있어 대규모 트래픽 분산에 자주 쓰인다.

기본 HTTP 프록시 설정 예시
- /etc/haproxy/haproxy.cfg 파일을 다음과 같이 구성할 수 있다.

frontend http_in
    bind *:80
    default_backend servers

backend servers
    balance roundrobin
    server web1 192.168.0.101:80 check
    server web2 192.168.0.102:80 check

TCP (L4) 프록시 구성
- SSL Termination을 하지 않고 TCP 수준에서의 프록싱을 할 경우 mode tcp 설정 사용.

frontend ssl_frontend
    bind *:443
    mode tcp
    default_backend tcp_servers

backend tcp_servers
    mode tcp
    server ssl1 192.168.0.201:443 check
    server ssl2 192.168.0.202:443 check

특징 및 고급 기능
- 상태 검사(Health Check) 기능 내장
- 접속 제한, 접속 분배, SSL 패스스루 등 다양한 고급 제어 기능 제공
- Stick Table, ACL, TCP-level rate limiting 등의 고급 정책 구현 가능
활용 사례
- 수십만 동시 접속이 필요한 환경의 L4/L7 로드 밸런서
- API Gateway 또는 DB 프록싱 구성에 활용

4.4 클라우드 기반 리버스 프록시 사례

클라우드 인프라에서는 리버스 프록시 역할을 SaaS 형태로 제공하는 서비스들이 존재한다. 인프라 유지 관리 부담이 줄어드는 대신, 구성 방식과 정책 적용은 각 플랫폼에 따라 상이하다.

1) Cloudflare

기본적으로 DNS를 통해 트래픽을 자사 인프라로 우회시키며 리버스 프록시 역할 수행
SSL Termination, 캐싱, WAF, Bot Protection 기능 제공
Zero Trust Access Gateway 등과 통합하여 인증 기반 접근 제어도 가능
설정은 웹 UI 및 API로 이루어짐

2) AWS Application Load Balancer (ALB)

L7 계층에서 작동하는 로드 밸런서로, Host, Path 기반 라우팅 지원
인증서 관리(ACM), HTTPS Termination, 대상 그룹 구성 등의 리버스 프록시 역할 수행
EC2, Lambda, ECS 등 다양한 AWS 리소스와 연계 가능

3) 기타 예시

Google Cloud Load Balancer, Azure Front Door
Fastly, Akamai 등 CDN 기반 고속 리버스 프록시 플랫폼

4) 활용 사례

다국적 사용자 대상 글로벌 서비스에서 성능 최적화 및 보안성 확보
멀티 백엔드 애플리케이션 구성에서 클라우드 네이티브 라우팅 적용

5. 리버스 프록시와 보안

5.1 DDoS 완화 및 IP 마스킹

리버스 프록시는 클라이언트와 실제 서버 사이에 위치하여 트래픽 흐름을 통제하고, 공격을 완화할 수 있는 첫 방어선 역할을 한다. 특히 다음과 같은 보안 기능을 수행한다:

1) IP 주소 은닉 (IP 마스킹)

리버스 프록시를 프론트에 두면 클라이언트는 실제 백엔드 서버의 IP를 알 수 없다.
공격자가 직접적으로 백엔드 IP를 알아내기 어렵기 때문에 타겟팅된 공격 차단에 유리.
클라우드 기반 CDN(Cloudflare, AWS CloudFront 등)과 함께 쓰일 때 특히 효과적.

2) DDoS 완화

초당 수천~수만 요청이 몰릴 때, 프록시 서버가 요청을 차단하거나 지연시켜 백엔드에 과부하가 전해지지 않도록 방어.
HTTP rate limit, connection 제한, challenge-response (예: CAPTCHA) 등의 기법이 활용됨.
일부 프록시 솔루션은 자동으로 IP 차단 목록(deny list)을 관리함.

3) 요청 큐잉과 시간 제한

요청을 큐에 넣고 일정 초과시 중단하는 방식으로 과부하 제어.
NGINX의 limit_req, HAProxy의 maxconn 옵션 등에서 구현 가능.

주의: 프록시 서버 자체가 DDoS 대상이 될 수 있으므로, L3/L4 수준의 방어(방화벽, 클라우드 보안 솔루션 등)와의 병행이 필요함.

5.2 웹 애플리케이션 방화벽(WAF)과의 통합

리버스 프록시는 WAF(Web Application Firewall)를 프론트에 통합시켜 웹 공격으로부터 백엔드를 보호하는 역할도 수행할 수 있다.

1) 공격 패턴 필터링

SQL Injection, XSS, Path Traversal, CSRF 등 주요 웹 공격을 요청 본문, 헤더, URL에서 탐지 후 차단.
OWASP Top 10에 기반한 룰셋을 활용하는 경우가 많음.
ModSecurity, AWS WAF, Cloudflare WAF 등과 연동 가능.

2) 보안 로깅과 감사

리버스 프록시 계층에서 모든 HTTP 요청/응답 로그를 수집해 분석 가능.
특정 URI 접근 시도, 비정상적인 User-Agent, 반복 요청 패턴 등 탐지에 활용됨.

3) 실시간 대응 시스템과의 통합

탐지된 공격에 대해 자동 차단, CAPTCHA 도입, IP 차단 등의 동작 가능.
일부 WAF는 리버스 프록시 레이어에서 inline 형태로 삽입되어 동작하며, 머신러닝 기반 위협 인식도 제공됨.

주의: WAF는 오탐이 잦을 수 있으므로 예외 규칙 작성과 테스트가 필수적임.

5.3 리버스 프록시 우회 공격 및 취약점

리버스 프록시도 완벽한 보안 장치는 아니며, 구성 방식이나 정책 설정에 따라 우회 공격 및 취약점이 존재할 수 있다.

1) IP Spoofing 및 헤더 위조

클라이언트의 실제 IP는 일반적으로 X-Forwarded-For, X-Real-IP 등의 헤더에 포함됨.
공격자가 이 헤더 값을 조작할 경우, 로그 조작 및 접근 제어 우회 가능.
서버 측에서 신뢰할 수 있는 프록시만 해당 헤더를 해석하도록 설정해야 함.

2) 경로 우회(Path Bypass)

특정 프록시 설정에서 필터링 우회가 가능한 경우 존재.
예: /admin은 차단했지만, /admin/../admin 형태로 우회 가능.
URI 정규화(normalization) 처리를 프록시에서 철저히 해야 함.

3) 내부 서비스 노출

리버스 프록시를 잘못 설정해 내부 API, 관리 콘솔, 테스트 인터페이스 등이 외부에 노출되는 사례가 있음.
location 또는 backend 설정에서 접근 제어 미비 시 발생.

4) 캐시 중독(Cache Poisoning)

특정한 악의적 요청으로 캐시된 콘텐츠를 조작해 다른 사용자에게 악영향을 미치게 함.
프록시 캐싱 로직에서 Host 헤더, 쿠키, 쿼리 파라미터 등을 정확히 분리/관리해야 방어 가능.

주의: 리버스 프록시 설정은 단순히 프록시 역할만 고려할 것이 아니라, 애플리케이션 레이어의 동작과 위협 모델까지 고려해 구성해야 함.

6. 리버스 프록시의 실무 구성과 튜닝

6.1 다중 백엔드 환경에서의 라우팅 전략

리버스 프록시는 하나의 클라이언트 진입점으로 여러 백엔드 서버 또는 서비스로의 요청을 분배하는 구조를 취한다. 효율적이고 유연한 라우팅 전략은 프록시의 핵심 역할 중 하나이며, 다음과 같은 방식으로 구성할 수 있다:

1) 패스 기반 라우팅 (Path-Based Routing)

요청 URL 경로에 따라 서로 다른 백엔드로 전달.
예: /api/ → API 서버, /static/ → 정적 파일 서버.
NGINX의 경우 location 블록으로 쉽게 설정 가능.

2) 호스트 기반 라우팅 (Host-Based Routing)

요청의 Host 헤더 값에 따라 백엔드 분기.
하나의 프록시 서버에서 여러 도메인을 호스팅할 때 활용됨.
예: api.example.com → API 서버, www.example.com → 웹 서버.

3) 헤더 기반 라우팅

요청 헤더의 특정 값(User-Agent, Authorization 등)에 따라 백엔드 분기.
모바일/데스크탑 분리, 인증 유무에 따른 백엔드 분리 등에 사용.

4) 가중치 기반 분산 (Weighted Load Distribution)

각 백엔드에 가중치를 부여하여 부하를 비율대로 분산.
NGINX, HAProxy에서 weight 설정 지원.

주의: 라우팅 전략은 단순한 리다이렉션이 아니라, 백엔드 상태와 트래픽 패턴에 따라 동적으로 조정될 수 있도록 구성해야 함.

6.2 Health Check와 Failover 설정

리버스 프록시는 백엔드 서버의 정상 동작 여부를 주기적으로 점검하고, 이상 발생 시 자동으로 트래픽을 다른 서버로 우회시킬 수 있어야 한다.

1) HTTP 기반 Health Check

정기적으로 /health, /ping 등 지정된 엔드포인트에 HTTP 요청을 보내 응답 상태 확인.
정상 응답 코드(예: 200 OK)가 오지 않으면 해당 백엔드를 비활성화.

2) TCP/ICMP 기반 체크

HTTP 서버가 아닌 경우, 단순 TCP 연결 또는 ping(ICMP)으로 확인.
DB 서버나 레거시 시스템에서 사용됨.

3) Failover (장애 조치)

기본 서버 장애 시 대체 백엔드로 트래픽 자동 전환.
HAProxy에서는 backup 옵션 사용, NGINX는 별도의 스크립트로 구현 가능.

주의: 헬스체크 주기와 타임아웃은 백엔드의 부하와 서비스 특성에 맞게 설정해야 함. 너무 잦거나 너무 느린 체크는 오탐 또는 느린 Failover로 이어질 수 있음.

6.3 성능 튜닝: 버퍼, Keep-Alive, 압축 설정 등

성능 최적화를 위해 리버스 프록시의 내부 처리 방식과 관련된 여러 요소를 세밀하게 조정해야 한다.

1) 버퍼 크기 조정

요청 헤더/본문, 응답 바디 등을 처리하는 내부 버퍼 크기를 설정.
NGINX 예: client_body_buffer_size, proxy_buffer_size, proxy_buffers.

2) Keep-Alive 설정

클라이언트 및 백엔드와의 TCP 연결을 재사용하도록 설정.
NGINX: keepalive_timeout, keepalive_requests, keepalive 설정.
HAProxy: option http-keep-alive, timeout client, timeout server.

3) Gzip 압축

정적 콘텐츠나 반복적인 텍스트 응답을 Gzip으로 압축하여 전송량을 줄임.
클라이언트가 Accept-Encoding: gzip을 보낼 경우 응답 압축 수행.
NGINX: gzip, gzip_types, gzip_min_length 설정.

4) 파일 전송 최적화

sendfile, tcp_nopush, tcp_nodelay 옵션 등을 활용해 대용량 파일의 전송 효율을 높임.
특히 정적 파일 서버로도 동작하는 경우 큰 성능 차이 발생.

참고: 무작정 높은 수치를 주는 것이 아닌, 실제 트래픽 특성, 사용 메모리, CPU 활용률 등을 고려해 설정하는 것이 중요함.

6.4 실시간 모니터링 및 로그 분석

리버스 프록시 서버는 트래픽 흐름의 관문이므로 실시간 상태 파악과 문제 대응을 위한 모니터링이 필수이다.

1) 접근 로그 및 에러 로그

모든 요청을 기록하여 IP, 경로, 응답 코드, 응답 시간 등을 확인.
NGINX: access_log, error_log.
HAProxy: 고급 로깅 기능과 syslog 연동 제공.

2) 통합 모니터링 툴 연동

Prometheus + Grafana, Datadog, Zabbix 등과 연동 가능.
QPS, 응답 시간, 에러율, 활성 세션 수 등 시각화 가능.

3) 상태 페이지 노출

NGINX: stub_status, HAProxy: stats socket 또는 stats page.
현재 연결 수, 백엔드 상태, 요청 처리량 등을 실시간 확인 가능.

팁: 로그는 분석을 위해서만 존재하는 것이 아니라, 이상 징후 감지 및 보안 침해 대응에도 활용되므로 로그 포맷 설계가 매우 중요함.

7. 마무리

다양한 플랫폼과 도구에 대해 가장 많이 다뤄야 했던 토픽인 것 같다. 역시 웹 관련 주제인가? 그라파나, 프로메테우스 등 써보고 싶었던 도구들도 얘기가 나오니 반가웠고, 웹서버 관련해서는 프로젝트를 수행하면서 간간이 접했던 내용들도 튀어나와 즐거웠다.

goldenGlow_21

안드로이드는 리눅스의 꿈을 꾸는가

이전 포스트

Daily CS) Computer Memory

다음 포스트

Daily CS) Reverse Proxy

Daily CS

Reverse Proxy

1. 프록시의 기본 개념과 종류

1.1 프록시 서버란?

1.2 Forward Proxy vs Reverse Proxy

Forward Proxy

Reverse Proxy

1.3 프록시 서버의 일반적인 사용 목적

1) 접근 제어 및 보안

2) 캐싱과 성능 최적화

3) 익명성 보장

4) 트래픽 로깅 및 모니터링

5) 로드 밸런싱

2. 리버스 프록시의 구조와 동작 원리

2.1 클라이언트 요청 처리 흐름

동작 흐름 요약:

예시:

2.2 백엔드 서버와의 연결 관리 방식

1) Keep-Alive 연결 유지

2) 커넥션 풀링 (Connection Pooling)

3) 세션 핀ning (Session Affinity)

2.3 DNS 및 포트 매핑과의 관계

2.3.1 DNS 구성

2.3.2 포트 매핑 및 NAT 관계

3. 리버스 프록시의 주요 기능

3.1 SSL 종단 처리 (SSL Termination)

3.2 로드 밸런싱 (Load Balancing)

3.3 캐싱 및 정적 콘텐츠 오프로드

3.4 요청 필터링 및 접근 제어

4. 주요 리버스 프록시 소프트웨어

4.1 NGINX의 리버스 프록시 구성

4.2 Apache HTTPD의 mod_proxy 설정

4.3 HAProxy의 TCP/HTTP 레벨 프록싱

4.4 클라우드 기반 리버스 프록시 사례

1) Cloudflare

2) AWS Application Load Balancer (ALB)

3) 기타 예시

4) 활용 사례

5. 리버스 프록시와 보안

5.1 DDoS 완화 및 IP 마스킹

1) IP 주소 은닉 (IP 마스킹)

2) DDoS 완화

3) 요청 큐잉과 시간 제한

5.2 웹 애플리케이션 방화벽(WAF)과의 통합

1) 공격 패턴 필터링

2) 보안 로깅과 감사

3) 실시간 대응 시스템과의 통합

5.3 리버스 프록시 우회 공격 및 취약점

1) IP Spoofing 및 헤더 위조

2) 경로 우회(Path Bypass)

3) 내부 서비스 노출

4) 캐시 중독(Cache Poisoning)

6. 리버스 프록시의 실무 구성과 튜닝

6.1 다중 백엔드 환경에서의 라우팅 전략

1) 패스 기반 라우팅 (Path-Based Routing)

2) 호스트 기반 라우팅 (Host-Based Routing)

3) 헤더 기반 라우팅

4) 가중치 기반 분산 (Weighted Load Distribution)

6.2 Health Check와 Failover 설정

1) HTTP 기반 Health Check

2) TCP/ICMP 기반 체크

3) Failover (장애 조치)

6.3 성능 튜닝: 버퍼, Keep-Alive, 압축 설정 등

1) 버퍼 크기 조정

2) Keep-Alive 설정

3) Gzip 압축

4) 파일 전송 최적화

6.4 실시간 모니터링 및 로그 분석

1) 접근 로그 및 에러 로그

2) 통합 모니터링 툴 연동

3) 상태 페이지 노출

7. 마무리

Daily CS) Computer Memory

Daily CS) CTI

0개의 댓글