[10분 테코톡] 여우의 Web Server와 WAS 정리

Web Server

HTTP 요청을 받고, 사용자가 필요한 자료를 HTTP로 보내는 컴퓨터

 

 

지금부터 동적 페이지와 정적 페이지 그리고 동적 페이지를 어떻게 처리하는지 정적 페이지는 어떻게 처리하는지 계속 웹 페이지데 대한 이야기만 나올 것이다. 그러다 보면 사람들이 '웹 서버는 웹페이지를 만들어 주는 서버인가? 그럼 웹 서버인데 만약에 JSON을 반환하거나 글자만 찍어주는 서버는 웹 서버가 아닌 건가?' 하는 오해가 생길 수가 있다. 하지만 우리가 실제로 화면에서 볼 수 있는 자료들은 HTTP 코드 안에 리스폰스 바디 안에 들어있는 내용이다. 바디 안에 있는 내용들이 다를 뿐 HTTP 프로토콜은 여전히 지키고 있다. 결론적으로 하이퍼텍스트 프로토콜로 송수신을 하는 모든 응답과 요청은 웹 서버에서 일어나는 일이다. 다만 이번에는 편의를 위해서 '웹 서버는 웹페이지만 반환한다'라는 식으로 가정을 하고 진행할 예정이다.

 

 

WAS

 

 

왼쪽 페이지는 Youtube이고, 오른쪽 페이지는 미국에 있는 회사의 소개 페이지이다. 둘 다 웹 페이지라는 점에서는 동일하지만 근본적으로 정말 큰 차이가 있다. 먼저 Youtube 페이지를 100번 새로고침하면 어떻게 될까? 새로고침 할 때마다 새로운 영상이 계속 보일 것이다. 서버에서 웹 페이지를 주기 전에 추천 알고리즘을 동작하고 그 알고리즘의 결과를 웹페이지에 넣어서 그 페이지를 보내 주어서 그렇다. 오른쪽 페이지는 100번이 아니라 100만번 새로고침을 해도 똑같은 내용만 보여줄 것이다.

 

 

이런 식으로 어떤 사용자가 언제 어디서 요청을 하든 똑같은 내용을 보여주는 페이지를 정적 페이지, 반대로 요청의 내용에 따라 그리고 요청을 보내는 사용자에 따라 뒤에서 어떤 연산이나 프로그램을 진행한 후에 그 결과를 반영한 웹페이지를 보내준다면 이는 동적 페이지 또는 웹 애플리케이션 이라 부른다.

 

왜 페이지 이야기를 하느냐 이 페이지의 종류에 따라서 웹 서버가 동작하는 방식이 완전히 달라지기 때문이다. 먼저 정적 페이지를 웹 서버가 다룰 때는 주소에 우리가 원하는 자료의 이름이 정확하게 찍혀 있다. .html 같은 확장자명까지 정확하게 표시를 한다. 그러면 웹 서버는 요청의 주소를 보고 자신이 가지고 있는 파일 시스템에서 이 자료가 있는지 찾아보고 있으면 찾아서 주면 된다.

 

 

동적 페이지의 경우에는 위와같이 이런 연산을 웹 서버는 수행할 줄 모른다. 그렇기 때문에 맨 처음에는 웹 서버가 받지만 이 요청을 그대로 웹 컨테이너에 넘겨준다. 웹 컨테이너는 동적인 컨텐츠를 만드는데 최적화된 어떤 프로그램 모듈이라고 생각하면 된다.

 

이 웹 컨테이너 안에는 어떤 것이 들어있을까? 서버를 Java로 개발하는 사람들이라면 이 웹 컨테이너 안에는 Servlet이란게 들어가 있을 것이다. Servlet을 다른 단어로 컨트롤러라고 표현할 수 있다. 어노테이션 붙여서 사용하던 그 컨트롤러 아래의 하나하나 메서드들이 전부 Servlet에 해당한다.

요청이 들어오면 그 요청을 수용할 수 있는 Servlet을 찾아서 프로그래밍을 진행한다. 그 프로그래밍에는 데이터베이스에 접근하는 것도 있을 수 있고 아니면 어떤 비즈니스 로직을 진행할 수도 있다. 로직을 진행하고 나면 결과물이 남을 것이다. 그 결과물을 웹 페이지에 적절하게 합쳐서 그 결과물을 응답할 것이니 합쳐줄 매니저가 필요하다. 그 매니저는 템플릿 엔진이 해줄 것이다.

템플릿 엔진은 뭘 할까? 웹페이지의 틀, 쉽게 말하면 붕어빵 틀 같은 거라고 생각하면 된다. 이 틀 안에 우리가 표현하고 싶은 데이터를 넣어두고 뚜껑을 닫았다가 열면 완성된 하나의 HTML, CSS 페이지가 나오게 되는 것이다. 이 페이지는 우리는 웹 서버로 갔다가 클라이언트에게 응답해 주면 동적 페이지에 대한 요청과 응답 작업이 완료가 되는 것이다.

 

그렇다면 WAS는 대체 어디 있는 걸까? 사실 웹 서버와 웹 컨테이너를 둘러싼 분홍색 배경이 WAS이다. 웹 애플리케이션 서버 (Web Application Server) WAS가 동적인 컨텐츠를 주로 다룬다고 많이들 알고 있을 것이다. 그 이유는 WAS가 이 웹 컨테이너, 실질적인 작업을 수행하는 이 컨테이너를 가지고 있기 때문에 그런 역할을 수행한다고 알고 있는 것이다.

그런데 WAS를 보면 웹 서버도 갖고 있고 웹 컨테이너도 가지고 있다. 그러면 WAS 하나가 정적인 거, 동적인 거 두 책임을 다 수행하고 있는데 너무 위험하지 않나요? 일리가 있다. 이것은 어떤 상황에 따라 달라질 수 있는데, 트래픽이 많지 않은  프로젝트라던가 아니면 작은 어플리케이션의 경우에는 트래픽이 많지 않으므로 과부하가 걸릴 일이 없다. 하지만 사용자가 많아지고 서버에 과부하가 걸릴 일이 많아지면 서버를 분산해야 된다. 이때 웹 서버는 동작이 가벼원 부하가 걸릴 일이 별로 없다.

 

 

웹 컨테이너가 대부분의 99%의 과부하를 책임지게 될 텐데 그럴 때는 웹 서버를 WAS로부터 뺀 다음에

 

웹 컨테이너만 가지고 있는 WAS를 증설하면 대규모 트래픽에도 안정적으로 대응할 수 있게 된다. 이렇게 되면 클라이언트와 다수의 WAS 사이에 웹 서버가 중간다리 역할을 하게 되는데 그럼 자연스럽게 이 서버의 역할이 엄청나게 많아지게 될것이다.

 

이때부터는 이 웹 서버는 서버라기보다는 하나의 어댑터, 마치 멀티탭 같은 것이 된다. 멀티탭 역할을 하면서 우리는 4개의 추가적인 역할을 맡게 된다.

 

1) 캐싱(Caching)

Naver같은 것도 동적인 페이지지만 결국에는 이미지 같은 것이 들어간다. 이미지는 정적이고 이런 것은 웹 서버가 가지고 있다가 똑같은 요청이 들어오면은 'WAS까지 갈 필요 없이 그냥 내가 줄게, 빠르게' 이런 역할을 하는 것이다.

*참고 :  [10분 테코톡] 썬의 캐싱 정리

2) 로드 밸런싱(Load Balancing)
WAS가 늘어났다고 해서 트래픽이 자동으로 분산되지는 않는다. 얘가 스스로 해주어야 한다.

*참고 :  [10분 테코톡] 찬, 레넌의 CI/CD와 무중단 배포 정리

3) Health Check
수명이 있어서 언젠간 죽는다. 그러면 분산을 할 때 죽은 서버는 빼고 보내줄 수 있어야 한다.

4) 리버스 프록시(Reverse Proxy)
웹 서버가 있는데 클라이언트가 자기 마음대로 웹 컨테이너로 바로 직격탄을 쏠 수도 있다. 그것을 방지하려면 무조건 웹 서버를 통해서만 상호작용할 수 있게 하고 웹 컨테이너의 주소나 존재를 클라이언트로부터 숨겨야 한다. 그 역할을 리버스 프록시로써 행하게 된다.

---

참고

https://www.youtube.com/watch?v=31tKPguQ1sk&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%ED%81%AC