WAS vs 웹 서버
이번 포스팅은 WAS와 Web Server에 대해서 알아가보겠습니다.
저도 처음에 백엔드 분야 공부를 시작하면서 위의 두 단어가 너무 헷갈렸습니다.
특히 어떤 부분에서 궁금했냐면 WAS안에 웹 서버가 내장되어있는데 왜 굳이 아키텍처를 구성할 때 웹 서버를 따로두지?
위의 의문점을 품고 직접 Tomcat을 이용하여 서버 API를 구축하다보니 웹 서버는 꼭 필요하겠구나라는 생각이 들었습니다.
그럼 두 개의 서버에 대해서 한 번 알아보겠습니다.
Web Server
클라이언트로부터 HTTP요청을 받어서 HTML이나 각종 리소스를 전달하는 컴퓨터
WAS(Web Application Server)
php와 jsp같은 언어들을 사용해서 동적인 페이지를 생성 할 수 있는 서버
위에서 두 개의 정의에 대해서 알아봤습니다.
제일 중요한 단어는 "동적인"과 "정적인"입니다.
주로 정적인 리소스들은 바뀌지 않습니다. 그래서 어딘가 캐싱해서 쓰면 더 효율적으로 사용할 수 있습니다.
그리고 동적인 리소스들은 로직 실행이 필요하기 때문에 별도의 서버를 설치해줘야합니다.
쉽게 말해서 정적인 리소스는 앞 단의 Web Server가 처리, 동적인 리소스는 뒷 단의 WAS가 처리해주면 됩니다.
여기서 드는 의문점이 있습니다. Tomcat과 같은 WAS는 안에 웹 서버를 내장하고 있는데 그것을 같이 쓰면 안될까요?왜 따로 써줘야되죠? 라고 질문할 수 있습니다. 그럼 따로 쓰면 좋은 장점을 여러가지 알아보겠습니다.
1. 책임 분산 및 로드 밸런싱
WAS는 오로지 로직을 수행해야하는 책임만을 갖게 됩니다. 그래서 용량이 큰 정적 리소스들에 대한 처리가 필요없어집니다.결과적으로 로드가 나눠진다고 볼 수 있습니다. 훨씬 속도가 빨라지겠죠?
2. 보안 강화
앞 단의 웹 서버를 한 대 더 가지면서 인증되지 않은 클라이언트로부터 공격이 올 경우 미리 방지하여 DB를 보호 할 수 있습니다.
3. 무중단 배포
만약 WAS와 웹 서버가 일체형으로 되어져 있다면 WAS가 다운되었을 경우 서비스가 중단되는 상황이 발생합니다.
이렇게 한 대의 WAS가 다운이 되어도 다른 WAS로 운영이 가능하다는 장점이있습니다.
이제는 왜 웹 서버와 WAS를 나눠서 설계해야하는지 이해가 가셨을거라 믿겠습니다.
그럼 구체적인 WAS동작에 관하여 살펴보겠습니다. 스프링 MVC형태로 설명드리겠습니다.
1. 클라이언트가 HTTP요청을 웹 서버에게 합니다.
2. 웹 서버는 요청 리소스가 정적이면 바로 응답해주고 동적이면 WAS로 요청을 넘깁니다.
3. WAS는 요청을 받고 요청에 맞는 서블릿을 생성하게 됩니다.
4. .xml또는 .gradle파일을 읽어들여 서블릿에 대한 Thread를 생성합니다.
5. request, response객체를 생성하여 서블릿에게 전달해줍니다.
6. 컨트롤러 -> 서비스 -> DB 순서로 로직을 진행하고 서비스는 결과를 서블릿으로 리턴해줍니다.
7. 그리고 View에 담을내용이 있으면 담고 결과를 담습니다.(Rest인지 아닌지에 따라 다릅니다.)
8. 웹 서버는 결과를 받아 클라이언트에게 전달해줍니다.
위의 내용이 틀릴수도 있습니다만.. 스프링 MVC의 구조와 동작방식에 대해서 알아봤습니다.
깊게 하려면 NGINX + TOMCAT을 직접사용해보면서 APP을 구동하는 과정을 담아야합니다.
시간이 조금 지나 위의 부분을 사용하여 APP을 구동하는 것을 포스팅해봐야겠습니다.
긴 글 읽어주셔서 감사합니다.