First written: 22-11-28
Uploaded: 22-11-28
Last modified: 23-02-28
Forward Proxy와 Reverse Proxy를 언급하기 전에 Proxy Server가 무엇인지부터 알아야 한다. 사전을 찾아보면 Proxy는 '대리(인)'라는 뜻을 가지고 있는데, Proxy Server란 Client 혹은 Server의 대리인 역할을 하는 컴퓨터라고 생각하면 된다. 더 일반적으로 설명하자면 어떤 컴퓨터의 대리 역할을 하는 컴퓨터로, 대리 역할을 수행할 컴퓨터 바로 앞단에 위치해 해당 컴퓨터와 인터넷망 사이를 중개해준다고도 설명할 수 있다.
Client 앞단에 Proxy Server가 붙으면 'Forward Proxy', Server 앞단에 Proxy Server가 붙으면 'Reverse Proxy'라고 일컫는다.
그림 출처: https://www.baeldung.com/nginx-forward-proxy
일반적으로 Proxy라고 말하면 주로 Forward Proxy를 말한다. 아마 Reverse Proxy는 서버를 만지는 사람, 특히나 인프라를 중심으로 만지는 사람만 그 존재를 알 수 있기 때문이지 않나 싶다. Client, 심지어는 Backend 개발자조차 본인의 서버가 Reverse Proxy로 돌아가고 있는지 어떤지에 대해 모를 수도 있다. 반면 Forward Proxy는 사용하는 Client가 직접 Proxy Server에 연결 및 접속하는 절차를 거쳐야 한다. 많은 회사에서 사내망을 이용하는데, 사내망을 구축하는 데에 이 기술이 쓰인다. 그래서 Proxy라고 하면 Forward Proxy를 말하는 것으로 인식이 된 것이 아닐까(익숙하게 봐온 것이 Forward Proxy이므로) 유추해본다.
Client가 어떤 Server로 어떤 요청을 보내면 Forward Proxy Server는 해당 요청이 인터넷망으로 나가기 전에 중간에서 요청을 받는다. 그리고 해당 요청을 받은 Forward Proxy Server는 본인이 대신 요청을 Server로 보내준다. 해당 기술은 이미 회사에서든 집에 있는 개인 컴퓨터에서든 많이 사용되고 있다.
우선 개인 컴퓨터에 사용되는 Forward Proxy에 대해 알아보자. 개인 컴퓨터에서도 어느 정도 Forward Proxy의 이점을 누릴 수 있다. IP를 우회하거나 보안을 향상시킬 수 있다는 장점이 있다. Client에서 Forward Proxy를 거쳐 나가게 되면 외부 인터넷망이나 요청을 받는 Server 입장에서 받게 되는 요청에 적힌 IP는 개인 컴퓨터의 IP가 아닌 Forward Proxy Server의 IP이다. 기타 담겨서 가게 되는 정보도 Forward Proxy Server의 정보이므로, 어느 정도 익명성을 보장받을 수 있다는 장점이 있다(물론 Forward Proxy는 기본적으로 인터넷에만 적용되어 게임이나 기타 서비스를 이용할 때는 해당 이점을 누리기 어려울 수 있다). 이를 통해 접속 제한이 걸려 있는 사이트를 우회하는 데에 사용될 수 있는 기술이다.
회사에서는 주로 어떻게 쓰일까? 회사에서는 주로 특정 콘텐츠에 대한 접속을 차단할 수 있다는 점에 착안해 Forward Proxy Server를 사용한다. 이를 테면 프로그래밍 교육용 캠퍼스에 있는 컴퓨터들에 Forward Proxy를 연결해두고 불법 사이트나 도박 사이트 혹은 주식 관련 페이지 등에 접속하려는 요청이 오면 이를 반려하도록 Forward Proxy를 설정해둘 수 있다.
또한 자주 방문하는 사이트들을 캐싱해둘 수 있는 기능을 제공하여, 사내 직원들이 자주 방문하는 사이트(회사 홈페이지 등)의 트래픽을 감소시킬 수 있음과 동시에 사내 네트워크 부하를 관리할 수도 있다. 당연히 캐싱은 속도 향상에도 도움을 준다. 부차적으로 사용률이나 로그 등을 기록하여 활용할 수도 있다.
Forward Proxy를 처음 접하고, IP를 우회할 수 있다는 말을 듣자 VPN이 떠올랐다. Forward Proxy와 VPN의 공통점과 차이점이 무엇인지 간단하게 짚고 넘어가자.
우선 둘 다 우리가 어떤 웹사이트로 요청을 보내기 전에 추가적인 공정이 들어와서, IP를 숨기거나(IP 주소를 마스킹한다고도 이야기한다) 웹 브라우저 내에서 익명성을 보장하고 보안성을 높이는 데에 탁월한 효과가 있다는 공통점이 있다. 많은 블로그 글들에서 두 방식은 아주 유사하지만 보안성에서 VPN이 조금 더 뛰어나다고 평가하고 있다. 왜일까?
우선 Forward Proxy는 응용프로그램 수준에서 동작한다. 반면 VPN은 운영 체제 수준에서 동작한다. 그러다보니 Forward Proxy는 웹 브라우저 등 특정 애플리케이션에서만 동작하는데, VPN은 특정 웹 브라우저뿐 아니라 다른 앱 및 기타 백그라운드 애플리케이션에서 발생하는 모든 트래픽에 대해 동작한다. 게임을 하고 있을 때, 백그라운드 앱이 돌아가고 있을 때 이 둘의 차이를 명확하게 느낄 수 있을 것이다.
또한 VPN은 트래픽 자체도 암호화한다. 그러다보니 아주 중요한 정보를 관리할 때에는 Forward Proxy보다는 VPN이 나을 수 있다. 다만 모든 트래픽에 대해 동작하고 그 트래픽 자체에 대해서도 암호화를 진행하는 까닭에 VPN이 Forward Proxy보다는 속도가 느릴 수 있다. 하여 아주 미세한 시간차도 중요한 공정에는 차라리 Forward Proxy가 나은 대안이 될 수 있다.
다만 개인 사용자 입장에서 VPN은 사실상 거의 대부분이 유료이고 Forward Proxy는 상대적으로 저렴하거나 공짜여서, 접근성에 약간의 차이가 있다.
참고로 Apache는 Forward Proxy를 지원하지만 Nginx는 지원하지 않는다.
그림 출처: https://rb.gy/eamftj
Forward Proxy를 반대로 가져다 놓으라는 의미에서 Reverse Proxy일까? 실제로도 맞는 말이다. Client의 반대편에는 항상 Server가 있는데, 그 서버 앞단에 Proxy Server를 구축한 것을 Reverse Proxy (Server)라고 부른다. 대개 인프라를 관리하는 담당자를 제외하면 깊게 탐구하게 될 일이 없는 기술이지만, 제한된 컴퓨터를 가지고 여러 서비스를 운영하려고 할 때에는 유용하게 쓰이는 기술이다.
Client에서 어떤 요청이 들어왔을 때 바로 WAS(Web Application Server)로 요청을 보내는 것이 아니라 Forward Proxy처럼 중개인이 중간에서 해당 요청을 받아 어느 WAS로 보내줄지를 결정하는 그런 Proxy Server를 Reverse Proxy라고 한다. 해당 요청을 받은 WAS는 필요한 처리들을 해 다시 요청이 온 Client에 응답을 보내는데 이때도 Reverse Proxy를 거쳐서 응답이 나가게 된다.
쉽게 구분하자면 WAS는 요청이 들어왔을 때 응답을 만들어내기 위해 실제 일을 하는 Server라고 생각하면 된다. 스택으로 이야기하자면 웹 백엔드 파트가 될 것이다. 반면 Web Server는 Nginx나 Apache처럼 웹 브라우저(Client)로부터 온 요청을 받아 해당 요청을 라우팅해주는 Server라고 보면 된다. 굳이 스택을 따지자면 인프라 파트가 될 것이다. 그 과정을 간단하게 살펴보자면, 아래와 같다.
따라서 웹 개발자로써 우리가 개발하는 모든 백엔드는 WAS라고 볼 수 있으며 여기에는 DB도 포함된다. 반면 Nginx와 같은 인프라에서 Reverse Proxy를 수행하고 있는 애플리케이션을 Web Server라고 볼 수 있다.
우선 보안을 높일 수 있다는 것이 장점이다. 기업의 예를 들자면, 보통 기업은 내부 네트워크와 외부 네트워크 사이에 DMZ라는 공간을 두게 된다. 그 공간은 1차 방화벽을 통해 외부 네트워크와 차단되어 있고, 내부 네트워크로 들어가려면 2차 방화벽을 통과해야 하는 그런 공간이다. 대개의 기업에서는 DMZ에다가 외부 네트워크에 서비스를 제공하는 Server들을 두게 된다. 예를 들자면 메일 서버나 DNS 서버 등을 예시로 들 수 있겠다.
그림 출처: https://rb.gy/eamftj
잘 생각해보면 WAS도 외부에 서비스를 제공하므로 DMZ에 WAS를 그대로 두어 바로 외부 네트워크와 소통하게 할 수 있다. 하지만 서버를 직접 구축해본 웹 개발자라면 알겠지만, WAS에 DBMS 관련된 정보들(DB table부터 id, password까지)이 같이 있는 경우가 많아(연결되어 있어야 하므로) 1차 방화벽이 뚫리고 WAS가 취약해지면 DBMS Server 역시 위험해질 수 있다는 단점이 있다.
반면 Reverse Proxy 서버만 바깥에 두고 내부 네트워크에 WAS를 배치하면 설령 1차 방화벽이 뚫리더라도 2차 방화벽에서 Bad Request에 대한 대처가 가능하므로, 보안이 높아진다고 할 수 있다. 또한 Client 요청의 end point가 Reverse Proxy가 되므로 WAS의 보안 자체가 높아지는 것도 장점이다.
또한 이전 글에서 살펴본 것처럼 Reverse Proxy에서는 load balancing이 가능하여 서버 부하나 이로 인한 문제 상황을 사전에 예방할 수 있다. 캐싱 기능도 제공이 되다보니 캐싱 기능을 통해 WAS가 해야 할 일의 범위를 줄여줌과 동시에 속도 면에서 더 좋은 서비스 제공이 가능해진다. 해당 내용은 여러 CDN들이 Reverse Proxy로 동작하는 캐시 Server라는 것을 안다면 더 명확하게 그림을 그릴 수 있을 것이다.
Canary testing은 애플리케이션의 새 버전이 출시되었을 때 해당 버전을 일부 사용자에게만 노출시켜 새로운 버전에서의 문제가 훨씬 많은 사용자들에게 영향을 끼치기 전에 해당 내용을 파악하고 대처하는 testing 기법이다. 이런 testing도 Reverse Proxy를 통해 이루어질 수 있다.
단점? 굳이 꼽자면 해당 내용을 이해하고 구축해야 해서 조금 어렵다, 정도일 것 같다.
이미 이전 글에서 Reverse Proxy에 사용되는 directive들을 살펴보았으므로, 여기서 언급되는 directive가 이해가 되지 않거나, directive들을 좀 더 상세하게 알고 싶다면 이전 글을 먼저 읽기를 추천한다. 여기서는 개인적으로 복습하고 정리한다는 느낌으로 Nginx가 Reverse Proxy를 구현할 때 핵심적으로 쓰이는 directive 몇 개만 가지고 예시를 들어보고 글을 마치려고 한다.
(/etc/nginx/nginx.conf)
upstream backend {
ip_hash;
server backend1.example.com/ weight=3;
server http://127.0.0.1:8001/;
server http://127.0.0.1:8002/ down;
server http://127.0.0.1:8003/ max_fails=3 fail_timeout=30s;
keepalive 32;
sticky cookie srv_id expires=1h domain=.example.com path=/;
}
upstream apiserver {
least_conn;
server http://127.0.0.1:9001/;
server http://127.0.0.1:9002/;
server http://127.0.0.1:9003/;
}
server {
server_name helloworld.com www.helloworld.com;
location / {
proxy_pass http://backend;
}
}
server {
server_name helloworld.api.com www.helloworld.api.com;
location / {
proxy_pass http://apiserver;
}
}
기본적으로 server_name에 location을 더한 url로 요청이 들어왔을 때 location의 proxy_pass에서 전달된 WAS로 요청이 pass된다. Client들에게 두 개의 서버를 서비스하는 Web Server의 모습이며, (아마도 CPU를 비롯한 여러 가지 것들이) 여유가 되는 상황이고 client가 많아 load balancing을 위해 WAS를 여러 개 가동시킨 상태에서 돌아가고 있는 모습이다.
참고사이트 :
포워드 프록시(forward proxy) 리버스 프록시(reverse proxy) 의 차이
VPN 대 프록시 서버: 차이점은 무엇일까요?
Reverse Proxy vs Load Balancer, 리버스 프록시 vs 로드 벨런서
Using Nginx as a Forward Proxy