스프링 웹 MVC에 들어가기에 앞서, 웹 애플리케이션에 대해 정리해보자.

HTTP와 웹 서버(Web Server)

웹 상에서 데이터를 주고 받을 때, 사용하는 프로토콜은 HTTP 이다.
HTTP 프로토콜 스펙에 맞게, 요청 또는 응답을 작성하고, 이를 주고 받음으로써 웹을 통해 통신한다.

웹 서버는 HTTP를 기반으로 데이터를 제공하는 서버(Server)이다. 웹 서버에 저장된 데이터를 원하는 사용자, 즉 클라이언트(Client)가 HTTP 스펙에 맞게 요청을 작성하여 웹 서버에 전송하면, 웹 서버는 이 요청을 처리하여 클라이언트가 원하는 데이터를 응답에 작성해서 되돌려준다.

하지만, 웹 서버에는 치명적인 단점이 있었는데, 웹을 통해 많은 정보를 주고 받을 수 있게 되면서,

동적인 리소스 제공의 필요성이 대두되었다.

즉, 특정 사용자 별로 동적으로 변하는 데이터를 제공해야하는 상황이 생긴 것이다.
기존의 웹 서버는 이런 기능을 할 수 없었다.

웹 애플리케이션 서버(WAS)

따라서, 동적 리소스를 제공할 수 있는 새로운 형태의 서버가 나오게 되었다.
웹 애플리케이션 서버는 웹서버와 동일하게 HTTP를 기반으로 기존의 웹 서버 기능을 포함하면서, 동시에 프로그램 코드 실행을 통해 애플리케이션 로직을 수행하여 동적 리소스를 제공할 수 있다.

WAS는 널리 사용되는 개념이기 때문에, 수많은 웹 애플리케이션 서버가 있다.
그 중, 자바(JAVA)를 프로그램 코드로 사용하는 웹서버가 바로 아파치 톰캣(Tomcat)이다.

자바에서 웹 프로그래밍을 위해 제공되는 인터페이스가 서블릿(Servlet)인데, 이 서블릿을 관리하는 서블릿 컨테이너 기능을 제공하는 소프트웨어를 WAS라고 생각하면 된다.

참고. WAS 만으로도 정적 리소스와 동적 리소스를 모두 제공할 수 있다면, 기존의 웹 서버는 필요 없는가?
-> WAS는 애플리케이션 코드를 실행하는데 더 특화되어있다. 즉, 동적 리소스를 제공하는데 더 특화되어있다는 말인데, 만약 WAS가 정적 리소스를 제공하는 역할도 담당하게 되면, WAS에 과부하가 생긴다. 따라서, 정적 리소스의 처리는 웹 서버가 WAS의 앞에서 처리하고, 동적 리소스의 처리만 WAS가 담당하는 것이 효율적이다.

아래의 이미지가 일반적인 웹서버와 WAS의 구조라고 생각하면 좋다.

서블릿(Servlet)과 WAS

자바에서 웹 프로그래밍을 위해 제공되는 인터페이스가 서블릿(Servlet)이라고 위에 짧게 설명했었다.

서블릿은 왜 필요한걸까? 서블릿의 필요성은 서블릿이 없다면 어떤 일이 발생하는지 생각해보면 된다.

웹 서버 또는 WAS에서 HTTP를 기반으로 통신하기 위해서 처리해야하는 업무는 다음과 같다.

왼쪽에 초록색으로 네모쳐져있는 부분을 보자. 초록색 네모에 해당하는 부분이 의미있는 비즈니스 로직에 해당한다. 그 외의 나머지 부분들은 HTTP 통신을 하기 위해서 해야하는 부가적인 업무들이다. 심지어 저 부가적인 업무들은 특정 개발자에게만 요구되는 업무들이 아니다. 웹 서비스를 개발하려면 모든 개발자들이 해야하는 공통적인 업무인 것이다.

저 부분을 하나부터 열까지 모든 개발자가 전부 개발한다고 생각해보자. 배보다 배꼽이 커지는 상황이 아닐수가 없다.

따라서, 자바는 위의 공통적인 부분들을 모아서 스펙으로 정의하고, 이를 개발자가 편리하게 사용할 수 있는 서블릿이라는 인터페이스로 제공하게 된 것이다. 그런데 여기서 끝이 아니다. 만약 WAS가 서블릿을 지원한다면, WAS가 웹 서버의 역할도 하면서 개발자 대신 서블릿을 관리하고, 필요한 서블릿을 상황에 따라 선택해서 호출하는 등의 기능을 수행한다. 이를 서블릿 컨테이너의 기능을 제공한다고 한다.

즉, 서블릿 컨테이너 기능을 하는 웹 서버, WAS 사용하면 개발자는 오로지 의미있는 비즈니스 로직에만 집중할 수 있고, 이는 개발의 생산성 향상으로 이어진다.

참고. 서블릿 객체는 싱글톤으로 관리된다.
HTTP 요청이 올 때마다 서블릿 객체를 매번 생성하는 것은 비효율적이기 때문이다. WAS 최초 로딩 시점에 서블릿 객체를 1개만 미리 만들어두고, 매 요청마다 만들어놓은 객체를 재활용한다. 따라서, 서블릿은 공유 변수 같은 싱글톤 패턴에서 문제를 일으킬 수 있는 요소를 가지면 안된다.

WAS는 추가적으로 동시 요청을 처리하기 위한 멀티 쓰레드 처리도 지원한다.

자바에서는 애플리케이션 코드를 순차적으로 실행하는 주체가 쓰레드이기 때문에, 쓰레드가 없다면 자바 애플리케이션의 실행이 불가능하다. 그런데, 쓰레드는 한번에 하나의 코드 라인만 수행할 수 있다.

웹 서비스 환경을 생각해보자. 웹 서비스가 한번에 한 명씩 사용하는 서비스인가? 아니다. 웹 서비스는 불특정 다수가 동시에 접근할 수 있는 서비스이다. 즉 웹 애플리케이션이 쓰레드를 하나만 갖고 있다면, 불특정 다수의 접근, 요청 등을 처리할 수 없다. 그러므로, 웹 애플리케이션은 기본적으로 멀티 쓰레드를 지원해야한다.

바로 이 멀티 쓰레드 처리를 WAS가 지원한다. 개발자는 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스코드를 개발하면 된다. Gooooooooooood!

참고.
WAS가 멀티 쓰레드를 지원하는 방식에 있어서, WAS는 매 요청이 올때 마다 새로운 쓰레드를 생성하는 것이 아니라, 쓰레드 풀을 이용한다. 따라서, WAS의 주요 튜닝 포인트는 쓰레드풀의 최대 쓰레드 수이다. 적절한 최대 쓰레드 수는 애플리케이션에 따라서 천차만별이기 때문에, 실제 배포전 성능 테스트를 통해 결정해야한다.