Reverse Proxy

여러분이 인터넷을 사용한다면 반드시 리버스 프락시(Reverse Proxy)를 사용하고 있다고 보면된다. 거의 모든 웹 애플리케이션이 리버스 프락시를 통해서 요청을 받기 때문에 클라우드 환경에서 개발을 하든, 온-프레미스 환경에서 개발을 하든 반드시 알고 있어야 하는 시스템이기도 하다.

리버스 프락시가 이렇게 중요한 이유는 리버스 프락시의 용도 때문이다. 리버스 프락시의 용도는 아래와 같다.

1. 로드밸런싱 : 리버스 프락시는 서버 애플리케이션 앞단에 놓여서, 클라이언트의 요청을 분산 처리한다. 하나의 서버에 부하가 몰리지 않도록 하며, 문제가 생긴 서버에 요청을 전달하지 않음으로써 서비스의 가용성을 높인다.
2. 웹 가속 : 로드밸런싱은 인바운드, 아웃바운드 트래픽을 압축할 뿐만 아니라, 요청을 캐시(cache) 함으로써 속도 성능을 높일 수 있다. 웹 서버가 처리해야 할 것을 캐시가 대신 처리해 줌으로 서버 부하를 줄일 수 있다.
3. 보안성 : 서버와 데이터베이스들 앞에 로드밸런서가 놓이는 구조이기 때문에 인터넷으로 부터의 공격을 1차적으로 방어하는 수단이 된다.

즉 인터넷과 서비스 네트워크를 연결하는 통로의 통로지기 역할을 수행한다고 보면 된다. 정확히는 인터넷으로 부터 전달되는 요청을 받아서 뒷 단에 있는 웹 애플리케이션으로 중계(Proxy) 하는 일을 한다. 이 중계의 방향이 웹 애플리케이션 입장에서 순방향(Forward)가 아닌 역방향(Reverse)이기 때문에 Reverse Proxy 이다. 예상 했겠지만 Forward Proxy도 사용한다. 내부에서 인터넷으로 나가는 요청을 중계하는 시스템인데, 리버스 프락시에 비해서는 상대적으로 접할 기회가 별로 없어서 크게 신경쓰지 않는다.

Reverse Proxy의 주요 기능

리버스 프록시 의 주요 기능은 아래와 같다.

1. 원본 서버를 인터넷으로부터 숨긴다.
2. 대부분의 리버스 프락시 솔류션들은 일반적인 웹 공격을 방어하는 웹 애플리케이션 방화벽(WAF)기능을 가진다.
3. SSL 오프로드(offload) 기능을 제공한다. 거의 모든 웹 서비스들은 HTTPS(SSL/TLS)로 트래픽을 암호화 한다. 이를 위해서 웹 서버들은 SSL 인증서를 업로드해야 한다. Reverse Proxsy가 SSL 인증서를 탑재하여 클라이언트와 암호화된 통신을 하고, 뒷 단에 있는 서버에는 암호화를 풀어서(복호화) 통신한다. 이렇게 하면 각 애플리케이션 서버마다 SSL 인증서를 관리 할 필요가 없다.
4. 통신 데이터에 대한 압축기능을 제공한다.
5. 리버스 프록시를 이용해서 A/B 테스트를 수행 할 수 있다.
6. 기본(Basic) HTTP 인증을 추가 할 수 있다.
7. 정적/동적 컨텐츠를 캐싱하여 속도를 높일 수 있으며, 서버 부하를 줄일 수 있다.
8. 리버스 프록시는 뒷 단의 애플리케이션 서버를 모니터링 한다. 애플리케이션 서버에 문제가 생기면, 해당 서버로 요청을 중단해서 클라이언트가 실패 메시지를 받지 않도록 한다.서버가 제대로 작동하면, 자동으로 부하를 분산시킨다.

Reverse Proxy와 고가용성

리버스 프록시는 뒷 단에 하나 이상의 서버를 둔다. 이 말은 몇 개의 서버에 문제가 생기더라도 계속해서 서비스를 할 수 있음을 의미한다. 서비스의 가용성을 높이기 위해서 리버스 프록시는 필수적으로 사용한다.

로드 밸런서와 Reverse Proxy

리버스 프록시의 주요 기능을 보면 "로드 밸런서"와 거의 동일하다는 것을 알 수 있다. 왜냐하면 로드 밸런서의 가장 중요한 역할이 "리버스 프록시의 기능을 제공" 하는 것이기 때문이다. 리버스 프록시의 구현체를 로드 밸런서로 보면 된다.

로드밸런서는 리버스 프록시의 핵심 기능을 가지면서 아래와 같은 추가적인 기능을 제공한다.

1. 정교한 라우팅 정책 : 경로기반 라우팅, 프로토콜 기반(HTTP, HTTPS) 라우팅, Cookie 기반 라우팅, 쿼리 기반 라우팅, 헤더 기반 라우팅, 메서드 기반 라우팅
2. 자체적인 카나리 또는 블루/그린 배포
3. A/B 테스트의 구현
4. 사람의 트래픽과 봇 트래픽을 구분하는 등의 높은 수준의 기능
5. 사용하기 쉬운 웹 기반의 관리 툴
6. 모니터링 시스템

Nginx와 Reverse Proxy

이 세상에는 리버스 프록시 기능을 제공하는 수많은 종류의 소프트웨어들이 있다. 가장 유명한 소프트웨어는 Apache와 NginX다. 이중 NginX에서의 리버스 프락시 설정에 대해서 살펴보려 한다. 이 문서는 리버스 프록시의 기술적 개념을 설명하는 것이지 개별 소프트웨어의 사용 방법을 설명하는 문서는 아니므로, 리버스 프록시를 이해하는데 도움이 되는 수준에서 설명할 것이다. NginX의 설치/설정과 관련된 것은 다른 강좌에서 자세히 다룰 것이다.

NginX는 오픈소스 HTTP 웹 서버다. 2010년경만 해도 Apache가 압도적인 1위의 웹서버 였으나, 지금은 NginX와 Apache가 시장을 양분하고 있으며 2021년에는 NginX가 Apache 점유율을 추월했다는 보고서도 나오고 있다.

아래와 같이 NginX를 이용해서 프록시 서버를 구성했다.

NginX Server는 유저 요청이 들어오면 192.168.0.5, 192.168.0.6, 192.168.0.7 셋 중 하나의 서버로 중계한다. NginX는 upstream 영역에 요청을 분배할 서버를 설정 할 수 있다. upstream이라는 용어가 생소 할 수 있는데, Origin(원본) 과 같은 의미다.

[code]

upstream test_proxy {
server 192.168.0.5;
server 192.168.0.6;
server 192.168.0.7;
}

[/code]

이렇게 upstream을 설정 한 후, 라우팅 룰 즉 각 요청에 대해서 어떤 upstream으로 중계 할지를 설정한다.

[code]

upstream test_proxy {
server 192.168.0.5;
server 192.168.0.6;
server 192.168.0.7;
}
server {
listen 80 default_server;
listen [::]:80 default_server;

root /var/www/html;

index index.html index.htm index.nginx-debian.html;

server_name _;

location / {
¦ proxy_pass http://test_proxy;
}
}

[/code]

URL 위치(location) / 로 향하는 요청은 test_proxy에 설정한 서버로 보내라는 의미다.

리버스 프록시 설정을 할 때, 분배 방법을 지정 할 수도 있다. 방법을 설정하지 않으면 라운드로빈 즉 모든 서버에 동등하게 요청을 분산한다. 처음 요청은 1번, 다음 요청은 2번, 3번, 1번, 2번 ... 식으로 순서대로 분산하는 방식이다.

[code]

upstream test_proxy {
server 192.168.0.5;
server 192.168.0.6;
server 192.168.0.7;
}

[/code]

least_conn으로 설정하면 연결이 가장 작은 서버로 요청을 중계한다.

[code]

upstream test_proxy {
least_conn;
server 192.168.0.5;
server 192.168.0.6;
server 192.168.0.7;
}

[/code]

기타 아래와 같은 분배 방법을 사용 할 수 있다.

• ip_hash : 클라이언트 IP 주소를 기준으로 요청을 분배한다. IP 주소가 같다면 같은 서버로 요청을 전송 한다.
• hash는 관리자가 정의한 key의 값을 이용해서 분산한다. 출발지 IP, 포트, URI 등으로 분산 할 수 있다.
• least_time은 레이턴시(지연)이 적은 서버로 요청을 전송한다.

프락시 서버의 핵심기능은 요청의 라우팅과 문제가 생긴 서버로 요청을 보내지 않는 것이다. 아래와 같이 upstream 서버에 대해서 health check를 할 수 있다.

[code]

upstream test_proxy {
least_conn;
server 192.168.0.5 max_fails=2 fail_time=10s;
server 192.168.0.6 max_fails=2 fail_time=10s;
server 192.168.0.7 max_fails=2 fail_time=10s;
}

[/code]

10초 동안 응답이 없으면 실패로 간주한다. 연속해서 2번 실패하면, 이 서버는 문제가 있다고 판단하여 upstream에서 제외 한다.

NginX 라는 특수한 애플리케이션을 대상으로 했지만, 어떤 리버스 프락시라도 기본적으로 지원하는 기능이기 때문에, 원리를 이해하는데는 큰 어려움이 없을 것이다.

클라우드와 리버스 프락시

클우드 환경에서도 리버스 프락시는 핵심 기능이다. AWS를 예로 들어보자면, AWS에 애플리케이션을 배포 할 때, 100% 들어가는 것이 리버스 프락시다. AWS는 ELB(Elastic Load Balancer)이라는 이름으로 서비스한다. 

• EC2(VM) 기반으로 애플리케이션을 배포 하든
• ECS(컨테이너) 기반으로 애플리케이션을 배포 하든
• EKS(Kubernetes) 기반으로 애플리케이션을 배포 하든

어떤 아키텍처에서도 ELB가 들어간다고 보면 된다. 왜냐하면 고강용성은 일차적으로 리버스 프록시를 통해서 달성하는 것이기 때문이다. 클라우드 업체가 제공하는 만큼 NginX와 같은 오픈 소스에 비해서 훨씬 다양한 기능을 제공한다.

• Auto scaling : 사용자 요청이 늘어나고 줄어듦에 따라서 자동으로 확장된다. 모니터링하면서 서버 올리고 내리고 할 필요가 없다.
• SSL 오프로드 : 인증서를 자동으로 관리해 준다.
• WAF와의 통합
• 모니터링 대시보드
• Web 기반의 편리한 관리 화면 : NginX에서처럼 손으로 작업 할 필요가 없다.
• oAuth2와 같은 인증 서비스와의 통합
• (실수에 의한)삭제 방지
• (요즘 핫한)Kubernetes 와의 통합

ELB같은 클라우드에서 제공하는 로드밸런서를 기본으로 사용하더라도, 시스템이 조금만 복잡해지면 내부에서도 NginX와 같은 로드밸런서를 사용한다.