📖 김영한 님의 <스프링 MVC 1편 - 백엔드웹 개발 핵심 기술> 강의를 보고 공부하며 정리한 포스트입니다.
웹이라는 것은 HTTP를 기반으로 통신합니다
웹을 이용한다는 것의 간략한 과정은 다음과 같습니다.
- 클라이언트가 웹 브라우저에서 URL을 입력합니다.
- 인터넷을 통해 서버에 접근합니다.
- 서버는 HTML을 만들어서 클라이언트에게 전달합니다.
그런데 클라이언트에서 서버로 데이터를 전송할 때, 그리고 서버에서 클라이언트로 데이터를 응답해줄 때, HTTP라는 프로토콜로 데이터를 주고 받습니다.
거의 모든 형태의 데이터를 HTTP로 주고 받습니다.
- HTML, TEXT
- 이미지, 음성, 영상, 파일
- API에서의 JSON, XML
거의 모든 형태의 데이터 전송이 가능하며, 서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용합니다.
웹 서버(Web Server)란
웹 서버(Web Server)란 HTTP를 기반으로 동작하는 서버입니다.
- 정적 리소스를 제공하며, 기타 부가 기능을 지원합니다.
- 정적 파일은 HTML, CSS, JS, 이미지, 영상 등을 말합니다.
- 웹 서버의 대표적 예로 NGINX와 APACHE 등이 있습니다.
웹 애플리케이션 서버(WAS, Web Application Server)
웹 애플리케이션 서버(Web Application Server, WAS)는 앞서 나온 웹 서버의 기능을 대부분 포함합니다. 큰 차이는 프로그램 코드를 실행해서 애플리케이션 로직을 수행할 수 있다는 것입니다.
- 마찬가지로 HTTP 기반으로 동작합니다.
- 정적 리소스를 제공합니다.
- 프로그램 코드를 실행해서 애플리케이션 로직을 수행합니다.
- 동적 HTML을 생성할 수 있습니다.
- HTTP API, REST API(JSON)를 지원합니다.
- Servlet, JSP, Spring MVC 같은 것들이 WAS에서 동작합니다.
- 대표적을 톰캣(Tomcat), Jetty, Undertow 등이 있습니다.
둘의 차이가 뭘까요?
- 웹 서버는 정적 리소스를 제공합니다.
- 웹 애플리케이션 서버는 애플리케이션 로직을 실행합니다.
하지만 둘의 용어와 경계가 모호합니다. 웹 서버도 프로그램을 실행할 수 있고, 웹 애플리케이션 서버도 웹 서버의 기능을 제공합니다.
언어에 따라 조금씩 다르지만 자바는 Servlet Container기능을 제공하면 WAS라고 보는 경향이 있습니다. (Servlet 없이 자바 코드를 실행하는 프레임워크도 있기 때문에 절대적인 것은 아닙니다.)
그러니 WAS는 애플리케이션 코드를 실행하는데 더 특화되어 있다고 보시면 됩니다.
개인적으로 추가하자면 현재(2024년도) 학교 전공 프로젝트나 부트캠프의 경우 대부분 프론트엔드와 백엔드를 분리해서 개발하는 경우가 많은데, 이때 리액트 같은 프론트엔드 결과물을 Nginx 등의 웹 서버가 클라이언트에게 제공하고, 스프링 같은 백엔드 결과물을 스프링 내장 톰캣이 제공하는 식입니다.
가장 간단하게는 WAS와 DB만으로 시스템 구성이 가능합니다
보통 실제 시스템을 구성해야 하는 경우, 가장 간단하게는 WAS와 데이터베이스로 최소한으로 구성할 수 있습니다.
WAS는 정적 리소스와 애플리케이션 로직 모두를 제공할 수 있기 때문입니다. WAS의 애플리케이션 로직에서 데이터베이스를 조회해서 필요한 HTML을 동적으로 만들어낼 수 있습니다.
그런데 WAS가 너무 많은 일을 담당하는데요?
맞습니다. 이렇게 WAS가 너무 많은 역할을 담당하게 되면 여러가지 문제점이 있습니다.
첫째, 서버 과부하의 우려가 있습니다.
둘째, 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있습니다. HTML, CSS, JS 등 정적 리소스는 시스템 적 코스트가 적습니다. 한 군데 저장해놓고 클라이언트에게 잘 제공하기만 하면 되기 때문입니다. 그러나 애플리케이션 로직은 비쌉니다. 비싸다는 것이 뭘까요? 예를 들어 보겠습니다. 주문을 처리해주는 로직이 비쌀까요? 이미지 하나를 보여주는 기능이 비쌀까요? 정적인은 파일명으로 찾아서 반환하면 그만입니다. 그러나 애플리케이션 로직은 데이터베이스도 조회하고, 데이터를 형식에 맞게 변환하고, 예외나 엣지 케이스를 처리하고, 다른 서버를 호출하는 등 매우 복잡합니다. 이러한 코스트에 차이가 있기 때문에 애플리케이션 로직이 정적 리소스 파일 제공 때문에 수행이 어려워지면 안 됩니다.
셋째, WAS 장애시 오류 화면조차 노출할 수 없습니다. 단일 장애점(Single point of failure)이라고도 합니다. WAS는 개발자가 직접 설계하고 구현하기 때문에 버그가 발생할 수 있고, 때문에 장애가 나기 쉽습니다. 이때 너무 많은 역할을 가진 WAS의 장애가 서비스 전체의 장애로 전파됩니다. HTML을 반환할 수 없으니, 유저는 오류가 났다는 화면조차 받을 수 없습니다.
때문에 일반적으로는 다음과 같이 구성합니다.
정적 리소스를 웹 서버가 처리합니다. 그러다 동적인 로직이 필요한 페이지의 경우 웹 서버가 이를 WAS로 넘깁니다. 그러면 해당 요청을 WAS가 처리해서 웹 서버로 반환, 그걸 다시 클라이언트에게 반환합니다.
이렇게하면 WAS가 서비스에 중요한 애플리케이션 로직을 전담할 수 있다는 장점이 있습니다. 웹 서버와 WAS가 업무를 분담하게 되는 것입니다. 그리고 또 하나의 장점이 있습니다.
시스템 리소스를 효율적으로 쓸 수 있습니다.
만약 정적 리소스가 많이 필요한 경우, 웹 서버만 그러한 요구에 맞춰서 증가(확장)시킬 수 있습니다. 반대로 애플리케이션 리소스가 많이 사용되면 WAS를 증설할 수 있습니다. (실제는 이것보다 조금 더 복잡하긴 합니다)
정적 리소스만 제공하는 웹 서버는 잘 죽지 않습니다
반면 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽습니다. 실제로 처음 배포를 해보려고 하면 사실상 개복치마냥 뭐가 좀만 마음에 안 들면 뻗어버립니다. 웹 서버의 역할은 단순히 파일을 클라이언트에 제공하는 것 뿐이기 때문에(추가적으로 로드벨런싱, 프록시, HTTPS 보안 연결 등에 사용되긴 합니다) 어쩌면 당연합니다.
WAS가 문제가 생길 확률이 높은 만큼 이에 대비하면 좋겠습니다. 웹 서버와 WAS가 분리되어 있으면 WAS에 문제가 생겼을 때, 클라이언트에게 오류화면을 제공해줄 수 있습니다. 물론 이는 화면을 제공하는 웹 서비스의 경우이므로, API만 제공하는 API 서버의 경우 WAS 서버만 구축해도 괜찮습니다.
