[Web] WAS와 Web Server 차이

3줄 정리

1. 웹서버는 정적페이지, WAS는 동적페이지 응답

2. 둘다 함께 배포하는 이유는 각자 잘하는 걸 하기 위함

3. 장고는 꼭 Webserver와 배포하자

 

 장고 배포와 관련된 글을 보면 WS(Web Server, 웹서버)와 WAS(Web Application Server, 웹어플리케이션서버)에 대해서 많이 볼 수 있다. 이름도 비슷해서 예전에는 사람마다 같은 걸 다르게 부르는 건가 싶었다. 

이와 관련된 내용을 찾아보면 사람마다 다른 얘기를 하고 있는 것을 볼 수 있었다. WAS와 WS를 분리해서 이야기 하기도 하고 합쳐서 동적으로 기능하는 웹서버라고 이야기 하는 사람도 있었다. 같은 걸 의미하지만 정의의 문제라고 생각했다. 하지만 내 나름대로의 정의는 필요하다고 생각했다. 이번 포스트에서는 웹서버와 웹어플리케이션을 나름대로 정리한 글이다. 잘못된 내용이 있다면 댓글을 달아주길 바란다.

 

1. 응답과 요청 (Request & Response)

이 질문에 답하기 위해선 먼저 웹서비스가 기본적으로 어떤 기술인지에 대해 생각해 보아야 한다.

웹 서비스의 가장 핵심은 무엇일까? 개인적인 생각으로는 요청(Request)와 응답(Response) 라고 생각한다. 

서버와 사용자가 존재하고 사용자가 요청(request)한 데이터를 서버가 찾아 응답(Response) 해준다. 

요청과 응답

 그렇다면 무엇을 요청하고 무엇을 응답해주는가? 바로 웹 서비스에서는 웹페이지를 요청하고 응답해준다. 웹페이지는 크게 정적 웹페이지와 동적 웹페이지로 나뉜다. 이 둘은 아래와 같은 차이를 갖고 있다.

 

1. 정적 페이지(Static Pages) : 사용자의 요청에 관계 없이 항상 동일한 페이지 

2. 동적 페이지(Dynamic Pages)  : 요청에 맞는 데이터를 반환

 

 이 둘의 차이는 서비스의 메인 페이지와 마이페이지 화면을 생각해보면 된다.

물론 요즘은 메인화면도 동적으로 사용자에 맞게 커스텀으로 구성되서 적절한 예시가 아닐 수 있지만 많은 서비스들의 메인화면은 불특정 사용자가 들어와도 동일한 페이지를 보여준다. 하지만 마이페이지에는 내가 즐겨찾기에 추가했거나 내 선택을 바탕으로 서비스에서 추천되어져 있는 것들이 웹페이지로 구성되어 있을 것이다. 즉 메인화면은 사용자의 요청과 관계없이 항상 동일하지만 마이페이지는 사용자가 서비스와 어떤 인터렉트를 했는지에 따라 달라지게 된다.

네이버 메인화면

2. WebServer 와 Web Application Server

 여기서 Web Server와 Web Application Server의 차이가 발생하게 된다. 간단하게 웹서버는 정적 페이지를 반환하고 WAS는 정적페이지와 동적페이지를 모두 반환할 수 있다라고 말할 수 있다. 두 서버의 기능이 겹친다. 이렇게 생각해 보는 것은 어떨까? WAS는 동적 페이지를 반환할 수 있는 Web 서버이다.

 

WAS는 두 페이지 모두 반환 가능한데 왜 웹서버와 같이 배포하는 걸까 라는 의문이 든다. 일단 결론부터 말하자면 더 빠르게 많은 요청을 처리하기 위함이다. 

 

웹서버는 정적페이지 응답을 잘하고 WAS는 동적 페이지 응답을 잘한다. 이 둘을 같이 배포하는 이유는 각각 잘하는 것만을 하게 해서 효율을 높이기 위함이다. 

 

물론 이러한 이유외에도 보안, 구조적인 유연성, 운영 같은 이유들이 있다. 간단하게 적어보자면

보안의 경우에는 SSL에 한 암호화 그리고 복호화 처리에 WebServer를 사용한다.

구조적 유연성에는 하나의 웹서버를 두고 여러 웹 어플리케이션을 사용할 수 있는데 이때 웹서버는 일종의 라우터 역할을 하게된다.

마지막으로 운영의 측면에서는 로드밸런싱이나, 장애극복(Fail Over, Fail Back) 그리고 무중단 운영에 유리하다. 

 

3. Django와 WebServer

 다른 언어의 웹프레임워크를 사용해보지 않아서 잘 모르지만 장고의 경우에는 서비스를 배포한다면 웹서버와 같이 배포해야한다. 먼저 장고는 파이썬을 기반으로 한 웹 프레임워크인데 파이썬은 아주 독특한 특징을 갖고 있다. 바로 GIL(Global Interpreter Lock)이다. 지금 이걸 여기서 모두 설명하는 건 무리가 있기 때문에 간단하게 이야기 해보면 하나의 스레드만이 인터프리터를 실행할 수 있다는 말이다. GIL과 관련해서 이런 비유를 자주 든다.

 

하나의 전화박스가  있다. 그 앞에는 이름이 "스레드" 라는 사람들이 부인에게 전화를 하려고 줄을 서있다. 그런데 한명의 스레드가 전화박스에 들어가면 전화 박스문을 잠궈서 다른 사람들이 못들어오게한다. 

파이썬 인터프리터 앞에 줄을 서있는 수많은 스레드들

즉 파이썬은 동시에 하나의 스레드만을 실행시킬 수 있다. 이러한 파이썬의 특징이 웹서비스에서는 단점으로 작용한다. 동시 요청이 많은 웹서비스 특성상 하나의 스레드 만을 실행시킬 수 있다면 한명의 사용자에게 하나의 페이지를 전달하고 나서야 그 다음 요청에 응답할 수 있다. 만일 앞선 요청이 상당히 시간이 오래 걸리는 요청이였다면 뒤의 사람은 그만큼 계속 기다려야하는 문제가 발생한다. 웹서버는 이러한 문제를 해결해주는데 아파치는 Prefork(요청마다 프로세스 생성)와 Worker(요청마다 스레드 생성)의 방식으로 Nginx는 이벤트 드리븐 방식으로 모든 커넥션을 비동기 방식으로 처리해준다. 이부분은 나중에 자세히 다루도록 하겠다.