스프링 MVC, 웹 어플리케이션 이해하기

 

웹, HTTP 기반으로 통신

---

현재 대부분의 웹은 통신할 때, HTTP 프로토콜을 사용해 통신한다. HTTP 프로토콜로 필요한 데이터를 송신하는데, 이 때 자료는 간단한 JSON 파일 뿐만 아니라 이미지, 음성 등 다양한 형태의 파일을 보낼 수 있다. 웹 브라우저에 URL을 치면 클라이언트는 서버에 HTTP 형식으로 요청을 보내고, 서버는 클라이언트에게 HTTP 형식으로 응답을 보낸다. 

즉, 클라이언트 → 서버, 서버 → 클라이언트는 모두 HTTP 기반으로 동작한다는 것으로 이해를 할 수 있다. 

 

웹 서버의 종류

---

웹 서버

• 웹 서버는 HTTP 프로토콜을 기반으로 동작함.
• 웹 서버는 정적 리소스(Static Resource), 기타 부가 기능을 제공한다. 

 

정적 리소스는 항상 동일한 형태를 제공해주는 리소스로 이해를 하면 된다. 주로 특정 폴더에 HTML, CSS, 이미지, 영상 파일을 둔다. 그리고 클라이언트의 요청이 오면, 서버에서는 그 파일들을 서빙해준다. 웹서버는 이처럼 정적인 형태의 리소스를 주고 받는데 많은 힘을 쓰는 것으로 이해할 수 있다.

 

WAS (Web Application Server)

• WAS는 HTTP 프로토콜을 기반으로 동작한다.
• 웹 서버의 기능을 포함한다(정적 리소스 제공)
• 프로그램 코드를 실행해서 비지니스 로직을 구현할 수 있음 → 동적으로 사용자마다 다른 것을 보여줄 수 있음.
• 동적 HTML, HTTP API(JSON), 서블릿, JSP, 스프링 MVC
• WAS는 톰캣 같은 것들이다.

 

웹 서버, 웹 어플리케이션 서버의 차이는? 

• 웹 서버는 정적 리소스를 제공하는 기능을 한다.
• WAS는 정적 리소스 제공 뿐만 아니라 어플리케이션 로직까지 동적으로 실행이 가능하다.

가장 큰 것은 위처럼 구분하기는 한데 경계가 애매하다고 한다. 웹 서버는 정적 리소스만 제공한다고 알려져 있지만, 플러그인을 사용하면 동적 비지니스 로직을 제공할 수 있기도 하다. 그리고 웹 어플리케이션 서버 역시 웹 서버의 정적 리소스 제공 기능을 수행하기도 한다. 

 

웹 시스템의 구성은?

• 웹 시스템의 최소 구성 요소는 WAS, DB다.

WAS는 정적 리소스의 조회와 서빙, 비지니스 로직의 조회와 서빙을 모두 제공 가능하다. 덧붙여서 DB 조회까지 가능하다. 따라서 웹 서버가 없어도 WAS만으로 웹 시스템을 구현할 수 있다. 그렇지만 그렇게 구현하게 되면 WAS에 몰리는 일이 많아지게 된다.

기본적으로 WAS는 비지니스 로직을 구현하는데, 비지니스 로직은 상대적으로 구현하는데 값이 비싼 편이다. 그렇지만 정적 리소스는 이미 만들어져 있는 것을 뿌리면 되기 때문에 WAS를 정적 리소스를 뿌리는데 쓰는 것은 WAS의 낭비라고 볼 수 있다. 또한, WAS는 뻗어버리면 '장애 관련 화면'을 출력할 수 조차도 없다. 

따라서, WAS 전에 웹 서버를 두어서 정적 리소스를 처리하도록 하고, WAS는 주요 어플리케이션 로직만 구현하도록 한다. 이렇게 분리적으로 운영할 경우에는 그에 따른 베네핏이 있다. 바로 서버의 수평 증설이 자유롭다는 것이다. 예를 들어 WEB 서버 대비 WAS에서 할 일이 많으면, WAS쪽에 서버를 더 붙여버리면 된다. 반대로 WEB 서버에 많은 리소스가 몰리면, WEB 서버의 증설을 더 하면 된다. 

또 다른 장점은 장애 처리다. WAS는 장애가 났을 경우 서버에 접속조차 되지 않기 때문에 현재 상태를 출력조차 하지 못한다. 반면 웹 서버는 굉장히 단순한 서빙만 하기 때문에 고장도 잘 나지 않을 뿐더라, 고장이 날 경우 이미 만들어진 오류 메세지를 출력만 해주면 된다. 따라서 이런 오류쪽 리스크도 잘 대응을 할 수 있게 된다.