[웹 서버] Proxy 서버와 Forward, Reverse 프록시

1. 프록시 서버란 무엇인가?

 Proxy는 대리, 대리인 의미를 가진 단어이다. 이 처럼 단어 의미에서 짐작해볼 수 있듯, 서비스를 제공하는 서버 대신 무언가를 수행하는 서버이다.

 프록시 서버의 주된 역할은, 웹 서비스 프로그램(이하 웹 서버)의 로드 감소이다.  좀 더 쉽게 이해하기 위해서 웹 서비스의 전체적인 과정을 아래의 그림을 보고 이야기 하자.

 일반적으로 웹 서비스는 크게 (1) 클라이언트 - (2) 웹 - (3) 웹 서버의 3개의 영역을 관통하면서 제공된다. 

 (1) 클라이언트는 서비스를 이용하는 사용자이며, 자신이 원하는 페이지, 파일을 (2) 웹을 통해 (3) 웹 서버에 요청하게 되며, (3) 웹 서버는 (1) 클라이언트의 요청에 맞는 데이터를 준비해서 응답한다.    

 위와 같이 연속된 웹 서비스 절차는 모든 요청마다 발생하게 된다. 물론 요청 한번마다 많은 수의 세부 요청이 존재할 수 있다는 것을 고려하자. (1개의 페이지당 평균 10~15개의 파일 요청이 발생한다.) 

 많은 사용자가 이용하게 되면 웹 서버는 동일한 절차를 중복해서 진행할 수 밖에 없으며, 매번 동일한 파일을 응답으로 전달해줘야하는 경우도 생긴다. (네이버 메인 페이지를 생각해보자.) 

 일반적으로 서버가 응답하는 내용에는 변하지 않는 정적 데이터와 사용자별, 시간별에 따라 달라지는 동적 데이터가 존재한다. 동적 데이터의 경우 응답하는 내용이 매번 달라지므로 중복되지 않는 요청이며, DB를 읽거나 계산등으로 인해서 정적 데이터에 비해서 응답하는 시간이 적게는 2배에서 많게는 10배 정도 오래걸린다. 

 그렇다면 앞서 말한바와 같이 중복되는 요청을 매번 처리하기에는 너무 많은 자원 낭비로 이어지게 된다.    

 따라서 기존 서버 앞단에 새로운 서버(프록시 서버)를 배치하고, 웹 서버가 중복되는 요청을 수행하지 않도록 바뀌지 않는 정적 데이터를 제공해보자.

 이 경우 정적 데이터에 대한 요청은 웹 서버까지 내려가지 않고 프록시 단에서 처리되어 (1) 클라이언트에게는 빠른 속도의 서비스를 (3) 서버에게는 불필요한 로드 감소 효과를 얻을 수 있다.

 이처럼 프록시는 "정적 데이터"를 제공하는 웹 서버 대신 제공하는 캐시의 역할을 수행한다.  

2. 혼란의 시작 : 포워드 프록시

여기까지는 대부분 쉽게 이해하는 내용이다. 그러나 프록시를 검색할 때 갑자기 포워드 프록시라는 키워드가 나오게되면 정신이 혼미해진다. 

 포워드의 정확한 의미를 이해하기 위해서는 몇가지 키워드를 알아야한다. 웹 서비스 프로세스에서 (1) 클라이언트 (2) 웹 (3) 서버로 구분하였는데, 일반적으로 웹을 제외(단순 데이터 송수신 매개체의 정적 역할)하고 우리는 클라이언트 서버 모델이라고 부른다.

 또한 컴퓨터 공학 전반에에 깔려있는 캡슐화(상세 처리 과정을 숨기는 것)를 바탕으로,  클라이언트는 서비스의 보이는 전면(Front)과 실제 서버를 수행하는 뒷면(Back)으로 구분하여 Front-end와 Back-end로 구분한다.

 다시 본론으로 돌아와서 지금까지 말한 프록시 서버는 클라이언트와 서버 사이에 있고, 클라이언트(Front-end)에게 미리 저장해둔 정적 데이터를 반환하는 역할을 한다. 

 따라서 전면(Front)으로 데이터를 밀어내는 역할을 수행하므로 Forward Proxy라고 한다. 일반적으로 말하는 프록시(Proxy)는 포워드 프록시(Forward Proxy)를 말한다. 따라서 대부분의 사이트에서는 Proxy, Forward Proxy를 혼용해서 표기한다. 

3.  차라리 백워드 프록시였으면 좋았을 것을.. : 리버스 프록시

 Proxy에는 Forward Proxy외에도 Reverse Proxy가 있다. Reverse Proxy는 포워드 프록시의 반대 방향으로 요청을 밀어내는 역할을 수행한다.

  즉, Backend 방향으로 요청를 밀어낸다. 웹 서버를 포함한 대부분의 서비스를 제공하는 서버를 구축할때는 Scale Out(병렬 확장)을 고려한다. 웹 서비스 서버의 3대 요소인 (Web Server, Was Server, DB Server) .. 못 본걸로 하자. 

 서버단에 다수의 웹서버를 두고, 매번 요청이 발생할 때마다 어떤 서버에게 이 요청을 처리하도록 지시할지 결정하는 역할을 수행한다. 

 

 예를 들어, FATC.CLUB에는 3개의 서버가 존재한다. (1) 블로그를 담당하는 fatc.club, (2) 블로그 내용을 구현하여 보여주는 etc.fatc.club 그리고 (3) IP 제공 서비스를 수행하는 ip.fatc.club 그리고 모든 요청은 1개의 Proxy 서버를 통해 들어온다. 그러면 어떻게 (1)~(3)을 구분해야 할까. 일반적으로 도메인을 보고 어떤 서버로 해당 요청을 밀어낼지 결정한다.  

 이처럼 다수의 서버를 Proxy 서버 하단부에 위치시켜 두고,  특정 조건(위에서는 도메인)에 맞는 요청을 적절한 서버에게 전달해주는 역할을 수행하는 것이 Reverse Proxy이다. 

 오해하지 말자. 하나의 Proxy 서버는 Reverse와 Forward를 모두 수행 할 수 있다. 다만 하나로 모든 것을 처리하기 힘들때 이를 둘로 나눈다.   

   Reverse Proxy를 이용하게 되면, 하나의 프록시로 다수의 서버(동일한 서비스이든지, 다른 서비스이든지 상관없음) 요청을 처리할 수 있다. 따라서 몇가지 잇점이 생기는데, 그중 라이트 유저에게 가장 큰 장점은 1개의 IP로 다수의 웹 서비스를 수행할 수 있다는 점이다. 이러한 프록시 기능은 대다수의 HTTP 프레임워크에서 제공한다. (Apache, NginX등)

 혼란스러울까봐 다시 한번 정리하자면, 프록시는 Forward Proxy와 Reverse Proxy 두 가지 기능을 모두 수행할 수 있으며, 이 기능들은 어디로 데이터를 밀어내냐에 따라 달라진다.

(글쓰는게 제일 헷갈린다)

 

4. 의외의 장점

 당연히 장점이 있으니까 쓰지 않을까? 정말 다양한 장점들이 존재하는데 모두 프록시 서버가 클라이언트와 서버 사이에 존재해서 발생되는 장점을 각각의 측면으로 구분해둔 것이다.  

 (1) 포워드 프록시의 캐싱 기능과 서버 로드 경감 

 프록시의 본래의 역할은 자주 사용되는 데이터를 확보해두고, 이를 캐싱(재활용)하는 것이다. 따라서 자연스럽게 서버의 로드가 감소하게 된다. 

 (2) 하나의 IP, 다수의 웹 서비스 사용자가 특정 도메인으로 요청을 전송하면, 대부분의 DNS는 도메인별 등록된 IP의 Well-known 포트 80(HTTP), 443(HTTPS)으로 이 요청을 릴레이한다.  

 따라서 1 Domain - 1 IP - 1 Server가 되어야 하나, IP의 한정된 수량(IPv4를 말함)과 가격적인 측면 그리고 관리 용이성등 다양한 이유로 1개의 IP로 다수의 웹 서버를 동작시킬 수 있다.

 (3) 실제 서버 직접 접근 차단 

 (2)과 같이 외부에 노출되는 IP는 프록시 서버의 공인 IP이며, 실제 동작하는 서버는 사설 IP를 할당받아 동작한다. 따라서 망 분리를 통해 클라이언트가 직접적으로 서버의 IP를 알 수 없기 때문에 보안이 다소 취약한 HTTP 프레임워크를 숨겨 이를 보호 할 수 있다. 다만 이것만 믿고 보안이 완벽하다고 생각하지 말자. 

 (4) IP 우회 

 지금까지 내용은 모두 서버측면에서 바라본 역할이다. 반대로 클라이언트 측에서 프록시 서버를 두고, 특정 서비스에 접근하게 된다고 생각해보자. 그렇다면 프록시 서버는 클라이언트 요청을 받아 특정 서비스에 접근하게 된다. 

 

 이 경우 특정 서비스의 요청 IP는 프록시 서버가 되어, 실제 서비스측에 클라이언트의 원래 정보를 숨길 수 있다. (공유기를 예로 들어보자. 공유기(공인 IP 1.2.3.4) 에 연결된 PC의 IP는 192.168.X.X의 IP를 가지고 특정 서비스에 요청을 전달하면, 특정 서비스를 제공하는 서버가 인지하는 클라이언트 IP는 1.2.3.4이다.)