웹서버와 WAS, 포워드 프록시, 리버스 프록시

 

이 글은 웹서버와 WAS, 그리고 포워드 프록시와 리버스 프록시에 대해 간단하게 작성한 글이다.

 

우선 위키백과에 나와있는 내용들을 보자.

웹 서버(Web server)는 HTTP 또는 HTTPS를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트(이미지 파일 등)을 전송해 주는 서비스 프로그램을 말한다. 

웹 애플리케이션 서버(Web Application Server, 약자 WAS)는 웹 애플리케이션과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크이다. 인터넷상에서 HTTP를 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해 주는 미들웨어(소프트웨어 엔진)로 볼 수 있다. 웹 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행이 된다.

여기서 확인할 부분은 웹서버는 HTML문서를 전송하고 웹 애플리케이션 서버는 동적 서버 콘텐츠를 수행한다는 것이다. 

 

웹서버와 WAS

우리가 브라우저에 특정 URL을 검색한다고 하자. 모든 사용자에게 고정적인 화면 즉,  html 파일이나 이미지  같은 정적인 페이지를 제공하는 것이 웹서버이다. Apache,Nginx,IIS 등이 있다.

그렇다면 변화가 있는 데이터는 어떨까? 사용자 정보마다 다른 정보를 보여주거나 서버 내부에서 상황에 따라 다른 데이터를 사용자에게 전달해 줘야 할 때가 있다. 이러한 기능을 수행하는 것이 WAS이다. Tomcat, JBoss, Jeus, Web Sphere 등이 있다. 데이터에 접근을 위해 데이터베이스에 연결을 한다.

 

일반적으로 사용자가 URL을 요청하였을 때, 정적인 요청은 웹서버에서 응답을 하고, 동적인 요청이 들어오면 해당 요청을 WAS로 전달하여 처리한다.

 

WAS가 나온 이유

그렇다면 WAS는 처음부터 있었던 것인가? 그것은 아니다. 예전에는 웹서버 만으로 다 처리를 하였다. 하지만 왜 웹서버를 웹서버와 WAS로 나눈 것인가? 웹의 복잡도가 점점 복잡해졌기 때문이다. 이후 효율적인 사용을 위해 분리를 하였다. 웹서버와 WAS로 나눠지면서 정적인 리소스와 동적인 리소스를 다루는 공간을 분리하여 하나 씩만 집중적으로 개발을 할 수가 있기에 효율이 증가되었다. 각 기능들을 관심사나 역할에 맞게 잘게 분리를 하게 되면 역할에 맞는 다양한 최적화 기법들을 적용할 수 있게 되고 문제의 범위를 좁힐 수 있다. 

예를 들면, 클라이언트의 요청에 의해 응답된 페이지에 글씨크기가 지나치게 크거나, 버튼이 이상한 위치에 놓여져있다면 이는 웹서버의 문제로 볼 수 있을 것이다. 

하지만 layer가 증가해서 담당해야 하는 영역이 넓어졌다는 문제도 있다. 이렇게 layer가 넓어지면서 프론트엔드 개발자와 백엔드 개발자의 구분이 명확해진 것이다. 

프론트엔드 개발자가 웹서버를 담당하고 백엔드 개발자가 WAS를 담당하는 것처럼 말이다. 

 

WAS를 구현하면서 생기는 장점

 그렇다고 서버 부분을 무조건 나눠야만 동작하는 것은 아니다. 웹서버에서는 정적인 부분에 더부어 동적인 부분도 처리할 수가 있다. PHP의 경우 WAS 없이 아파치나 nginx만을 통해 동적인 요청 처리가 가능하다. 그리고 WAS는 동적인 부분을 담당하지만 웹서버가 담당하는 대부분의 기능도 수행이 가능하다. 

하지만 위에서 언급했다시피 역할을 나눠서 효율적으로 동작을 해야 한다. WAS는 DB 접근 데이터를 다루는 로직을 처리하는데 집중해야 하고, 웹서버는 사용자가 집적 보는 화면을 구현하는데 집중해야 한다.

그리고 사용자가 많아지는데 만약 WAS가 정적페이지까지 담당하면, 서버부하가 커지고 동적 데이터 처리도 지연되면서 사용자의 요청에 응답하는 시간이 지연될 것이다. 그러면서 효율성은 크게 떨어질 것이다. 아래의 사진을 봐보자.

 

 

위의 사진은 하나의 웹서버의 여러개의 WAS가 연결되어 있는 모습이다. 사람들이 집중되면서 생기는 대량의 트래픽을 하나의 웹서버로만 감당해 내기가 힘들다. 그래서 이러한 부하를 분담시키기 위해 WAS를 여러대를 연결할 수가 있다. 그래서 부하가 고르게 분담이 되고 웹서버에서는 어디 WAS에 연결시킬지를 알고리즘에 따라 정하면 된다. 그리고 하나의 WAS가 문제가 생겨도 다른 WAS들이 있기 때문에 그 WAS를 사용하지 않도록 차단만 하면 사용자는 문제가 있는지도 확인하지 못할 것이다. 이러한 방식을 로드밸런싱이라고 하고 WAS를 두면서 로드밸런싱을 효율적으로 할 수 있다. 

 

서버 보안측면에서도 장점이 있다. 사용자는 웹서버만을 접근하기 때문에 데이터베이스에 접근하는 WAS의 주소를 특정하기가 어렵다. 그러기에 해커들의 DDOS공격 등을 막는데 유용하다.

 

이러한 웹서버와 WAS의 관계는 리버스 프록시의 구조를 가진다고 할 수 있다. 

 

포워드 프록시, 리버스 프록시

 

웹 아키텍처를 구성할 때 떠오르는 것 중 하나가 프록시 서버 설정이다. 프록서 서버에는 크게 포워드 프록시, 리버스 프록시로 나누어 진다. 위에서 웹서버와 WAS의 구조가 리버스 프록시의 구조를 갖는다고 언급을 하였지만 정확한 의미는 무엇일까? 한번 확인해 보자.

 

프록시 서버

위키백과에서는 프록시 서버를 아래와 같이 정의한다. 

프록시 서버(proxy server)는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부른다.

위의 설명처럼 중계역할을 하는 것이 프록시 서버이다. 이러한 프록시 서버는 보안, 캐싱 등의 도움을 준다.

 

클라이언트는 서버로 요청을 통해 데이터를 가져온다. 만약 같은 내용을 여러 번 요청한다면 그만큼 처리하는 비용이 많이 들것이다. 

하지만 프록시 서버가 중간에 있다면 중복 요청에 대하여 동일한 응답이 필요할 때, 서버까지 접근하지 않고 프록시 서버에서 미리 저장된 응답을 계속 클라이언트로 넘겨주면 되니 서버에 부하를 줄이고 클라이언트에겐 더 빠르게 응답을 할 수 있다.

 

프록시 서버에는 두 가지 종류가 있다.

'포워드 프록시'와 '리버스 프록시'이다. 먼저 포워드 프록시부터 확인해 보자.

 

포워드 프록시

 

포워드 프록시 서버는 아래 그림처럼 클라이언터 뒤에 놓여 있다. 하나의 내부망(LAN: Local Area Network)에서 클라이언트가 요청을 하면 서버로 요청하는 것이 아니라 프록시 서버로 먼저 요청을 한다. 프록시 서버는 인터넷으로 들어가 해당 서버로 다시 요청을 하여 클라이언트로 전달을 해주는 것이다. 

서버가 받은 IP는 포워드 프록시 서버의 IP이기 때문에 서버는 클라이언트가 누구인지를 특정하지 못한다.

이러한 방식으로  정부, 학교, 기업 등과 같은 기관은 기관 내의 사람들에게 제한적인 인터넷 사용을 준다. 이는 방화벽과 같은 개념으로 해당 서버에 직접적인 접근을 막고, 특정 사이트에 접속하는 것을 사전에 방지할 수 있다.

그리고 프록시 서버가 특정 요청으로 인한 페이지의 정보를 캐싱하여 동일한 요청이 오면 캐싱된 정보를 그대로 전달할 수 있다.

 

리버스 프록시

 

리버스 프록시는 위의 그럼처럼 서버 앞에 놓여 있다. 클라이언트가 인터넷에 들어가 서버에 요청하면 리버스 프록시를 먼저 접근하게 되고 리버스 프록시에서 서버로 요청하여 데이터를 가져오는 것이다.

포워드 프록시 서버는 위의 그림처럼 클라이언터 뒤에 놓여 있다. 하나의 내부 망에서 클라이언트가 요청을 하면 서버로 요청하는 것이 아니라 프록시 서버로 먼더 요청을 한다. 프록시 서버는 인터넷으로 들어가 해당 서버로 다시 요청을 하여 클라이언트로 전달을 해주는 것이다. 

즉, 포워드 프록시는 클라이언트를 대신하여 요청을 한다면 리버스 프록시는 서버를 대신하여 응답을 하는 것이다. 

클라이언트는 리버스 프록시를 서버를 먼저 호출하기 때문에 실제 서버의 주소를 특정할 수 없다. 그렇기에 실제 서버의 정보를 숨길 수 있다. 그렇기에 해커들의 DDOS와 같은 공격들을 방지할 수 있다.

이렇게 하여 얻는 이점 중 하나는 보안이다. 보통 기업의 네트워크 환경에서는 DMZ(Demilitarized Zone)라고 부르는 구간이 있다. DMZ는 내부 네트워크에 존재하면서 외부 네트워크와 상호작용을 할 수 있는 구간으로 외부 네트워크와 내부 네트워크의 사이에 있다고도 할 수 있다. 내부 네트워크에서는 외부 네트워크와 단절되어 이메일, DNS, FTP, 웹검색 등 인터넷 서비스를 사용할 수 없다. 오직 DMZ를 통해서만 외부와 소통을 할 수가 있다. 

일반적으로 리버스 프록시 서버를 DMZ에 두고 실제 서버는 내부망에 위치시킨다.

포워드 프록시와 마찬가지로 캐싱을 할 수가 있다. 그리고 트래픽 분산을 위한 로드 밸런싱도 가능하다. 이는 위에서 설명한 웹서버와 WAS 구조로도 볼 수도 있다.

 

 

 

 

참고자료

 

https://inpa.tistory.com/entry/NETWORK-%F0%9F%93%A1-Reverse-Proxy-Forward-Proxy-%EC%A0%95%EC%9D%98-%EC%B0%A8%EC%9D%B4-%EC%A0%95%EB%A6%AC

🌐 Reverse Proxy / Forward Proxy 정의 & 차이 정리

https://firework-ham.tistory.com/23

Forward Proxy와 Reverse Proxy 차이점

https://story.pxd.co.kr/1647

웹서버와 WAS(Web Application Server)